[Top][Contents][Index] |
LilyPond — 使用方法
このマニュアルは LilyPond バージョン 2.25.20 で配布されるプログラムの実行方法について説明します。さらに、効率的な使用方法について提案します。 |
1 lilypond を実行する | 操作方法 | |
2 convert-ly を使ってファイルを更新する | 入力ファイルをアップデートする | |
3 lilypond-book を実行する | 文章と楽譜を統合する | |
4 外部プログラム | LilyPond と他のプログラムを混合する。 | |
5 LilyPond 入力ファイルの記述に対する提案 | 効率的な使用方法とバグ対処方法 | |
付録 | ||
---|---|---|
Appendix A GNU Free Documentation License | このドキュメントの使用許諾書 | |
Appendix B LilyPond インデックス |
このマニュアルと他のドキュメントの関係について、あるいは、このマニュアルを他の形式で読む方法についての情報は、マニュアル を参照してください。 マニュアルのいずれかを見失ってしまった場合、https://lilypond.org/ にマニュアルがすべて揃っています。 |
[ << Top ] | [Top][Contents][Index] | [ convert-ly を使ってファイルを更新する >> ] |
[ < Top ] | [ Up : Top ] | [ 通常の使用方法 > ] |
1 lilypond
を実行する
この章では LilyPond を実行するための細かな規定について詳述します。
1.1 通常の使用方法 | ||
1.2 コマンド ラインの使用方法 | ||
1.3 エラー メッセージ | ||
1.4 一般的なエラー |
[ << lilypond を実行する ] | [Top][Contents][Index] | [ convert-ly を使ってファイルを更新する >> ] |
[ < lilypond を実行する ] | [ Up : lilypond を実行する ] | [ コマンド ラインの使用方法 > ] |
1.1 通常の使用方法
たいていのユーザは GUI から LilyPond を実行します。まだ実行したことがないのであれば チュートリアル を読んでください。 Lilypond ファイルを書くのに代替のエディタを使用するのであれば、そのエディタのドキュメントを読んでください。
[ << lilypond を実行する ] | [Top][Contents][Index] | [ convert-ly を使ってファイルを更新する >> ] |
[ < 通常の使用方法 ] | [ Up : lilypond を実行する ] | [ lilypond を呼び出す > ] |
1.2 コマンド ラインの使用方法
この節にはコマンド ラインで LilyPond を使用するための追加情報が含まれます。これにはプログラムに追加オプションを渡す必要があるかもしれません。さらに、いくつかの特別なプログラム (midi2ly
など) はコマンド ラインからしか利用できません。
ここで ‘コマンド ライン’ とは、OS の中にあるコマンド ラインを意味します。Windows ユーザは ‘DOS シェル’ や ‘コマンド シェル’ ‘コマンド プロンプト’ という言葉の方が馴染みがあるかもしれません。MaxOS X ユーザは ‘ターミナル’ や ‘コンソール’ という言葉の方が馴染みがあるかもしれません。MaxOS X ユーザは追加のセットアップが必要かもしれません。MacOS X を参照してください。
OS のコマンド ラインの使用方法についての説明はこのマニュアルが扱う範囲ではありません。コマンド ラインに馴染みがない場合は、その内容を扱っている他のドキュメントをあたってください。
lilypond を呼び出す | ||
LilyPond の基本的なコマンド ライン オプション | ||
LilyPond の高度なコマンド ライン オプション | ||
環境変数 | ||
再配置 | ||
chroot jail 環境で LilyPond を実行する |
[ << lilypond を実行する ] | [Top][Contents][Index] | [ convert-ly を使ってファイルを更新する >> ] |
[ < コマンド ラインの使用方法 ] | [ Up : コマンド ラインの使用方法 ] | [ LilyPond の基本的なコマンド ライン オプション > ] |
lilypond
を呼び出す
lilypond
実行可能形式ファイルはコマンド ラインから以下のように呼び出されます。
lilypond [option]… file…
拡張子を持たないファイル名で呼び出された場合、.ly が最初に試されます。stdin から入力を読み込む場合には、file に対してダッシュ (-
) を使用します。
filename.ly が処理されると、lilypond は出力として filename.pdf を作り出します。いくつかのファイルを指定することもできます。その場合、それらのファイルは個々に処理されます。1
filename.ly が複数の \book
ブロックを含んでいる場合、残りの score は
filename-1.pdf から始まる番号付きのファイルに出力されます。さらに、output-suffix
がベース名と番号の間に挿入されます。例えば、 filename.ly が以下の内容を含んでいる場合、
#(define output-suffix "violin") \score { … } #(define output-suffix "cello") \score { … }
LilyPond は filename-violin.pdf と filename-cello-1.pdf を出力します。
標準シェルで LilyPond を使う
LilyPond はコマンドラインアプリケーションなので、LilyPond を呼び出すために ‘シェル’ の機能をうまく利用することができます。
例えば,
lilypond *.ly
は、カレントディレクトリのすべての LilyPond ファイルを処理します。
コンソール出力をリダイレクトする(例えばファイルへ)のも有用でしょう。
lilypond file.ly 1> stdout.txt lilypond file.ly 2> stderr.txt lilypond file.ly &> all.txt
上記コマンドはそれぞれ ‘普通の’ 出力、‘エラー’ のみ、‘すべて’ 、 をテキストファイルにリダイレクトします。あなたの使用しているシェル、コマンドプロンプト (Windows)、ターミナルやコンソール (MacOS X) がリダイレクトをサポートしているか、あるいは構文が異なるかどうかは、そのシェルのドキュメントを調べてください。
以下は、カレントディレクトリ以下のすべての入力ファイルを再帰的に探し、処理する例です。出力ファイルは元の入力ファイルのあるディレクトリではなく、コマンドを実行したディレクトリに置かれます。
find . -name '*.ly' -exec lilypond '{}' \;
これは MacOS X ユーザでも使えるでしょう。
Windows ユーザは
forfiles /s /M *.ly /c "cmd /c lilypond @file"
スタートメニューから
スタート > アクセサリ > コマンドプロンプト
とたどるか、検索ウィンドウで ‘コマンドプロンプト’ と入力して、
コマンド プロンプト
を起動し、これらのコマンドを入力します。
または、入力ファイルを含むすべてのサブフォルダを含む、最上位のフォルダを明示的に指定できる /p
オプションもあります;
forfiles /s /p C:\Documents\MyScores /M *.ly /c "cmd /c lilypond @file"
最上位フォルダ名がスペース文字を含む場合は、パス全体をダブルクオーテーションで囲む必要があります。;
forfiles /s /p "C:\Documents\My Scores" /M *.ly /c "cmd /c lilypond @file"
[ << lilypond を実行する ] | [Top][Contents][Index] | [ convert-ly を使ってファイルを更新する >> ] |
[ < lilypond を呼び出す ] | [ Up : コマンド ラインの使用方法 ] | [ LilyPond の高度なコマンド ライン オプション > ] |
LilyPond の基本的なコマンド ライン オプション
以下のオプションがサポートされます。
-d
,--define-default=
var[=
val]LilyPond の高度なコマンド ライン オプション を参照してください。
-e
,--evaluate=
expr.ly ファイルを解析する前に Scheme expr を評価します。複数の
-e
オプションが与えられた場合、それらは順番に評価されます。Scheme 表記は
guile-user
モジュールの中で評価されます。そのため、expr の中で(define-public a 42)
のような定義を使いたいのならば、コマンド ラインで以下を使用して、lilypond -e '(define-public a 42)'
.ly ファイルの先頭に以下を含めます.
#(use-modules (guile-user))
Note: Windows ユーザはシングル クォートではなく、ダブル クォートを使う必要があります。
-E
,--eps
EPS ファイルを生成します。
このオプションは LilyPond のコマンドラインオプションに
--ps
, と-dlilypond-book-output
, を指定するのと同じです。-f
,--format=
format(主な)出力ファイルのフォーマットを指定します。
format
の選択肢はps
,pdf
, またはpng
です。例:
lilypond -fpng foo.ly
svg
フォーマットやeps
フォーマットを出力するには-dbackend
オプションを用います。 LilyPond の高度なコマンド ライン オプション を参照してください。-h
,--help
使用方法の要約を表示します。
-H
,--header=
fieldヘッダ フィールドをファイル BASENAME.field に吐き出します。
例えば、 foo.ly という入力ファイルが以下の内容を含んでいる場合、
\header { title = "bar" } \score { c1 }
コマンド
lilypond -H title foo.ly
を実行すると、文字列
bar
を含んだプレーンテキストファイル foo.title が作られます。-i
,--init=
fileinit ファイルとして file をセットします (デフォルト: init.ly)。
-I
,--include=
directorydirectory を入力ファイルのサーチ パスに相対パスとして追加します。デフォルトではカレントディレクトリのみが検索されます。
複数の -I オプションを与えることができます。検索はカレントディレクトリから開始され、入力ファイルが見つからない場合は、最初の -I で指定されたディレクトリ、そして二番目の -I で指定されたディレクトリ、というように検索します。
Note: チルド記号 (
~
) を -I と共に使用すると、シェルによっては予期しない結果をもたらす場合があります。Windows ユーザは、ディレクトリのパスの最後にスラッシュを含める必要があります。
-j
,--jail=
user,
group,
jail,
dir[このオプションは OS が
chroot
機能をサポートする場合のみ有効です。特に、 Windows はサポートしていません。]lilypond
を chroot jail 環境で実行します。(訳者: chroot jail 環境とはセキュリティのためにカレント プロセスに対してルート ディレクトリの位置を変更すること。)--jail オプションは、Web サーバ経由で LilyPond 譜刻を提供する時や LilyPond が外部ソースから送られてきたコマンドを実行する時に、
--dsafe
よりも自由度の高い代替手段を提供します。 (LilyPond の高度なコマンド ライン オプション を参照してください。)--jail
オプションはコンパイル プロセスの開始直前にlilypond
のルート ディレクトリを jail に変更します。それから、ユーザとグループを user と group に変更して、カレント ディレクトリを dir に変更します。これにより、jail (牢獄) から抜け出せないことを (少なくとも理論上は) 保証します。--jail
を指定したlilypond
の実行は root (ユーザ名) として行う必要があります。通常、これはsudo
を用いた安全な方法で行います。jail のセットアップは比較的複雑な問題です。LilyPond がソースをコンパイルするのに必要とされるものすべてを jail の内部 で見つけられるということを保証しなければならないからです。一般的なセットアップには以下の項目が含まれます:
- 専用のファイルシステムをセットアップする
noexec
,nodev
,nosuid
などのセーフ オプションでマウントするための専用ファイルシステムを作成すべきです。こうすることで、LilyPond から実行可能形式ファイルを実行したり、デバイスに直接書き込むことは不可能になります。専用のパーティションを作成することを望まないのなら、適当なサイズのファイルを作成し、それを使用してループ デバイス (ループバック デバイス) をマウントしてください。専用ファイルシステムはさらに、LilyPond が許可されたディスク容量以上には書き込めないということを保証します。- 専用のユーザをセットアップする
jail 内部で LilyPond を実行する際、低い権限を持つ専用のユーザとグループ (仮に
lily
/lily
とします) で行うべきです。このユーザが書き込み可能なディレクトリが 1 つだけ存在すべきであり、それを dir に渡します。- jail の準備をする
LilyPond は実行中にいくつかのファイルを読み込む必要があります。それらのファイルをすべて jail にコピーしておきます。それらのファイルが本当のルート ファイル システムで存在しているパスと同じパスにコピーします。LilyPond インストールの内容すべて (例えば、/usr/share/lilypond) をコピーすべきです。
問題が発生した場合、その原因を突き止める最も簡単な方法は
strace
を使って LilyPond を実行することです。これによりどのファイルが見当たらないのかがわかります。- LilyPond を実行する
noexec
でマウントされた jail の中では、外部プログラムを実行することは一切できません。そのため、外部プログラムを必要としないバックエンドで LilyPond を実行しなければなりません。すでに述べたように、jail モードでの LilyPond の実行はスーパーユーザ権限で行われなければならず (もちろん、その権限はすぐに外されます)、たぶんsudo
を使います。LilyPond が使用可能な CPU 時間を数秒に制限する (例えば、ulimit -t
を使って) というのも良い方法です。さらに、OS がサポートしているのなら、割り当て可能なメモリ容量を制限するというのも良い方法です。chroot jail 環境で LilyPond を実行する も参照してください。
-l
,--loglevel=
levelコンソール出力の饒舌さを level にセットします。取り得る値は以下の通りです:
NONE
何も出力しません。エラー メッセージさえも出力しません。
ERROR
エラー メッセージだけを出力します。警告や進捗メッセージは出力しません。
WARN
警告とエラー メッセージを出力し、進捗メッセージは出力しません。
BASIC
基本的な進捗メッセージ (成功メッセージ)、警告、それにエラー メッセージを出力します。
PROGRESS
すべての進捗メッセージ、警告とエラー メッセージを出力します。
INFO
進捗メッセージ、警告、エラーそれに追加の実行情報を出力します。 これがデフォルトです。
DEBUG
饒舌なデバッグ出力を含む、出力可能なメッセージをすべて出力します。
-o
,--output=
file-o
,--output=
folderデフォルトの出力ファイルとして file をセットします。セットした名前のフォルダが存在する場合、 folder に入力ファイルから取ったファイル名で出力されます。どちらの場合にも適切な接尾辞が追加されます (つまり、PDF ならば拡張子 .pdf が追加されます)。
-O
,--pspdfopt=
key ¶-
key へ PS/PDF 最適化を設定します。選択肢は:
size
非常に小さい PS/EPS/PDF ドキュメントを生成します。 これがデフォルトです。
LilyPond の Scheme コマンドラインオプション
-dmusic-font-encodings='#f'
と-dgs-never-embed-fonts='#f'
を指定した場合と同じです。TeX
pdfTeX, LuaTeX, XeTeX ドキュメントにインクルードされるのに最適化されたファイルを生成します。
LilyPond の Scheme コマンドラインオプション
-dmusic-font-encodings='#t'
と-dgs-never-embed-fonts='#f'
を指定した場合と同じです。TeX-GS
LilyPond によって生成された PDF を TeX ドキュメントに複数インクルードしたい場合は、このオプションを使い、TeX によって生成された PDF を Ghostscript で後処理してください。
LilyPond の Scheme コマンドラインオプション
-dmusic-font-encodings='#t'
と-dgs-never-embed-fonts='#t'
を指定した場合と同じです。
--ps
PostScript を生成します。このオプションは
-fps
と同じです。--png
各ページの図を PNG フォーマットで生成します。このオプションは
-fpng
と同じです。画像の解像度を N DPI に設定するには以下のようにします。
-dresolution=N
--pdf
PDF を生成します。これがデフォルトで、
-fpdf
と同じです。-s
,--silent
進行状況を表示せず、エラーメッセージのみ表示します。これは
-lERROR
と同じです。-v
,--version
バージョン情報を表示します。
-V
,--verbose
冗長表示モードにします: 読み込むすべてのファイルのフル パスを表示して、時間情報などを表示します。これは
-lDEBUG
と同じです。-w
,--warranty
GNU LilyPond の保証責任を表示します。(GNU LilyPond には保証責任はありません!)
[ << lilypond を実行する ] | [Top][Contents][Index] | [ convert-ly を使ってファイルを更新する >> ] |
[ < LilyPond の基本的なコマンド ライン オプション ] | [ Up : コマンド ラインの使用方法 ] | [ 環境変数 > ] |
LilyPond の高度なコマンド ライン オプション
オプション -d は LilyPond の Scheme 関数 ly:set-option
のコマンドラインインタフェースです。つまり、ここで示しているすべてのオプションは .ly ファイルの中で設定することが可能です。
-d
,--define-default=
option-name[=
value]-d
,--define-default=no-
option-name内部 Scheme シンボル option-name に value を設定するのと同じです。例えば、コマンドラインオプション
-dbackend=svg
は LilyPond 入力ファイルに
#(ly:set-option 'backend 'svg)
を書くことと同じです。
value が指定されない場合、
#t
(真偽値以外を取る場合は、おかしな結果になるかもしれません)が使われます。option-name に接頭辞no-
を付けると、そのオプションは ‘off’ つまり#f
が使われます。例えば、-dpoint-and-click='#f'
は
-dno-point-and-click
と同じです。
[‘#’ 文字は多くのシェルでコメントの開始を意味することに注意してください。そのため、それを含む式は常にクォートすることをお勧めします。]
次の表に、サポートされているすべてのオプション名と値を示します。Scheme コード内では、オプション値は関数 ly:get-option
で読み取ることができます。
anti-alias-factor
num(与えられた因数 num を用いて) 高解像度で描画して、その結果をスケールダウンすることにより、
PNG
画像の輪郭がギザギザになることを防ぎます。デフォルト:1.0
。aux-files
boolbool が
#t
ならば、eps
バックエンドオプションを使っているときに .tex, .texi, と .count ファイルを生成します。デフォルト:#t
。backend
symbolsymbol を LilyPond 出力のバックエンドとして使用します。 選択肢は:
ps
こればデフォルトです。 Postscript ファイルは
TTF
,Type1
, それにOTF
フォントを埋め込みます。フォントのサブセットは作成されません。日本語のような ‘東洋’ の文字セットを用いるとファイルが非常に大きくなる可能性があることに注意してください。PDF 出力には
ps
バックエンドが使われます。出力された PS データは Ghostscript のps2pdf
で後処理され、デフォルトでフォントのサブセットが作成されます。eps
lilypond-book
コマンドのデフォルトです。これは、1 つのファイルにすべてのページとフォントを埋め込んだものと、ページ毎に分離しフォントを埋め込まない eps ファイルの、両方を吐き出します。svg
ページ毎の SVG (Scalable Vector Graphics) ファイルが全ページ分作られます。音楽グリフはベクタ画像に変換されますが、文字フォントは SVG ファイルには埋め込まれません。 そのため、テキストや歌詞の最適な描画を得るためには、SVG ビュアーに関連するテキストフォントが必要となります。SVG ビュアーが対応していないことがあるので、‘フォントリスト’ や ‘フォントエイリアス’ を使用しないことをお勧めします。Web Open Font Format (WOFF) ファイルを使うときには、追加の
-dsvg-woff
スイッチが必要となります。
clip-systems
boolbool が
#t
なら、楽譜から断片を取り出します。これを使用するには、\layout
ブロックにclip-regions
関数が定義されている必要があります。音楽の断片を抽出するを参照してください。 -dno-print-pages と一緒に用いられた場合、断片は全く出力されません。デフォルト:#f
。crop
boolbool が
#t
なら、すべての楽譜とヘッダをマージンなしの ‘単一ページ’ 出力に合わせます。デフォルト:#f
。datadir
データファイル パスの接頭辞です。読み取り専用で、設定しても効果がありません。
debug-skylines
boolbool が
#t
なら、スカイライン (訳注: 行ごとのオブジェクトの最高位置と最低位置を線で表示するもの) を表示します。デフォルト:#f
。delete-intermediate-files
boolbool が
#t
なら、コンパイルの途中で作成される使用しない中間ファイル .ps を削除します。デフォルト:#t
。embed-source-code
boolbool が
#t
なら、出力される PDF ドキュメントに LilyPond ソースファイルを埋め込みます。デフォルト:#f
。eps-box-padding
num出力される EPS の左端に num mm の余白を追加します。デフォルト:
#f
(余白追加しないことを意味します)。font-export-dir
stringPostScript ファイルとしてフォントをエクスポートするディレクトリを string に指定します。デフォルト:
#f
(カレントディレクトリを意味します)。 これは、次に示すように、フォントを埋め込まずに PDF を作成し、後でフォントを Ghostscript で埋め込む場合に便利です。$ lilypond -dfont-export-dir=fontdir -dgs-never-embed-fonts foo.ly $ gs -q -dBATCH -dNOPAUSE -sDEVICE=pdfwrite \ -sOutputFile=foo.embedded.pdf foo.pdf fontdir/*.font.ps
注:
font-ps-resdir
とは異なり、このメソッドは Ghostscript 9.26 以降で CID フォントを埋め込むことはできません。注:
font-ps-resdir
と同様に、 TrueType フォントを埋め込むと文字化けが発生するため、このオプションは TrueType フォントをスキップします。文字化けしないようにするには、gs-never-embed-fonts
を使用します。これは、TrueType フォントをその名前に関係なく埋め込みます。デフォルト:
#f
(エクスポートしないことを意味します)。font-ps-resdir
string(string として) ディレクトリを設定して、後でフォントを埋め込むために使用する PostScript リソース ディレクトリのサブセットをビルドします。これは、次に示すように、フォントを埋め込まずに PDF を作成し、後でフォントを Ghostscript で埋め込む場合に便利です。
$ lilypond -dfont-ps-resdir=resdir -dgs-never-embed-fonts foo.ly $ gs -q -dBATCH -dNOPAUSE -sDEVICE=pdfwrite \ -I resdir -I resdir/Font \ -sOutputFile=foo.embedded.pdf foo.pdf
注: Ghostscript の
-I
オプションで指定した場合、特別な意味があるため、 Resource という名前を含むディレクトリは指定しない方がよいでしょう。注:
font-export-dir
とは異なり、このメソッドは Ghostscript 9.26 以降で CID フォントを埋め込むことができます。注:
font-export-dir
と同様に、 TrueType フォントを埋め込むと文字化けが発生するため、このオプションは TrueType フォントをスキップします。文字化けしないようにするには、gs-never-embed-fonts
を使用します。これは、TrueType フォントをその名前に関係なく埋め込みます。デフォルト:
#f
(ビルドしないことを意味します)。gs-load-fonts
boolbool が
#t
なら、Ghostscript 経由でフォントを読み込みます。LilyPond 出力ファイルのフォントはすべて参照のみが含まれるようになり、 Ghostscript による後処理で実際のフォントに解決する必要があります。デフォルト:#f
。gs-load-lily-fonts
boolbool が
#t
なら、LilyPond のフォントを Ghostscript 経由で読み込みます。LilyPond 出力ファイルの音楽フォントはすべて参照のみが含まれるようになり、 Ghostscript による後処理で実際のフォントに解決する必要があります。他のすべてのフォントは通常通り出力されます。デフォルト:#f
。gs-never-embed-fonts
boolbool が
#t
なら、Ghostscript が TrueType フォントのみを埋め込むようになり、他のフォーマットのフォントは埋め込まれません。デフォルト:#f
。help
boolbool が
#t
なら、このヘルプを表示します。デフォルト:#f
。include-book-title-preview
boolbool が
#t
なら、プレビュー画像にブック タイトルを含めます。デフォルト:#t
。include-eps-fonts
boolbool が
#t
なら、システム毎の EPS ファイルにフォントを含めます。デフォルト:#t
。include-settings
stringグローバル設定のファイルとして string をインクルードします。このファイルは楽譜の処理が開始する前にインクルードされます。デフォルト:
#f
(グローバル設定ファイル無しを意味します)。job-count
numnum ジョブで、並列処理します。デフォルト:
#f
(並列処理無しを意味します)。log-file
string出力をログファイル string.log にリダイレクトします。デフォルト:
#f
(ログファイル無しを意味します)。max-markup-depth
numマークアップ ツリーの階層の最大値を num に設定します。それよりも深い階層を持つマークアップがある場合、そのマークアップは終了していないと見なされて、警告が表示され、null マークアップが返されます。デフォルト:
1024
。midi-extension
stringMIDI 出力ファイルのデフォルトのファイル拡張子を .string に設定します。デフォルト:
"midi"
。music-strings-to-paths
boolbool が
#t
なら、記譜フォントを用いるテキストをパスに変換します。デフォルト:#f
。paper-size
extra-quoted-stringデフォルトの紙面サイズを extra-quoted-string に設定します。文字列をエスケープ記号付の 2 重引用符で囲む必要があることに注意してください。デフォルト:
"\"a4\""
。pixmap-format
symbol画像出力のための GhostScript の出力フォーマットを symbol に設定します。デフォルト:
png16m
。point-and-click
boolbool が
#t
なら、PDF と SVG 出力に ‘ポイント&クリック’ リンクを付け加えます。ポイント&クリック を参照してください。デフォルト:#f
。preview
boolbool が
#t
なら、通常の出力に加えてプレビュー画像を作成します。デフォルト:#f
。このオプションはすべてのバックエンド (
pdf
,png
,ps
,eps
, それにsvg
) でサポートされますが、scm
ではサポートされません。入力ファイル名 file でバックエンド format を使った場合、出力ファイル名は file.preview.
format で、タイトルと楽譜の最初の段を含みます。\book
ブロックや\bookpart
ブロックが使われている場合、\book
,\bookpart
, それに\score
のタイトルが出力に譜刻され、\paper
変数print-all-headers
が#t
にセットされている場合は各\score
ブロックの最初の段も譜刻されます。通常の出力を抑制するには、必要に応じて -dprint-pages オプションまたは -dno-print-pages オプションを使ってください。
print-pages
boolbool が
#t
なら、すべてのページを生成します。デフォルト:#t
。-dpreview や -dcrop を使う場合は -dno-print-pages を組み合わせると有用です。
protected-scheme-parsing
boolbool が
#t
なら、パーサでインライン Scheme のエラーが発生しても処理を続けます。#f
に設定されている場合、エラー終了して、スタック トレースを表示します。デフォルト:#t
。relative-includes
boolbool が
#t
なら、\include
コマンドを処理するとき、インクルードするファイルをカレント ファイルからの相対位置で検索します。#f
なら、ルート ファイルからからの相対位置で検索します。デフォルト:#f
。resolution
num生成する
PNG
画像の解像度を num dpi に設定します。デフォルト:101
。safe
boolbool が
#t
なら、.ly 入力ファイルを信用しません。デフォルト:#f
。Web サーバ経由で LilyPond 譜刻が利用可能な場合、--dsafe オプションか --jail オプションのどちらかを 指定する必要があります。--dsafe オプションはインライン Scheme コードが無茶をする – 例えば、以下のような – ことを防ぎます。
% 正しく書くのはあまりにも危険 #(s ystem "rm -rf /") % 破壊的ではないが悪意がある { c4^$(ly:gulp-file "/etc/passwd") }
-dsafe オプションはインライン Scheme 表記を特別なセーフ モジュールの中で評価します。これは Guile の safe-r5rs モジュールに由来しますが、scm/safe-lily.scm でリスト アップされている LilyPond API 関数のいくつかも追加されています。
さらに、セーフ モードでは
\include
は許可されず、TeX 文字列の中でバックスラッシュを使うこともできません。また、セーフ モードでは LilyPond 変数を Scheme にインポートすることもできません。-dsafe はリソースの過使用を検出 しません ので、このオプションを指定してもプログラムをハングさせられる可能性があります – 例えば、サイクリック (巡回) データ構造をバックエンドに埋め込むことによってです。 そのため、LilyPond を一般公開する Web サーバで使用する場合、プロセスのCPU とメモリ使用を制限すべきです。
セーフ モードは多くの有用な LilyPond 楽譜断片がコンパイルされることを妨げます。
--jail はさらに安全な代替手段ですが、セットアップにかかる手間も増えます。LilyPond の基本的なコマンド ライン オプション を参照してください。
separate-log-files
boolbool が
#t
なら、入力ファイル file1.ly, file2.ly, … に対するログをファイル file1.log, file2.log, … に出力します。デフォルト:#f
。show-available-fonts
boolbool が
#t
なら、使用可能なフォント名をリスト アップします。加えて LilyPond は fontconfig の設定そのものを表示します。デフォルト:#f
。strip-output-dir
boolbool が
#t
なら、出力ファイル名を構築する時に入力ファイルのディレクトリを使用しません。デフォルト:#f
。strokeadjust
boolbool が
#t
なら、PostScript に線幅補正 (stroke adjustment) を強制します。このオプションは普通、PDF ファイルが PostScript 出力から生成されている場合に意味があります (線幅補正は、低解像度のビットマップ デバイスに対して自動的に有効になります)。このオプションを指定しない場合、PDF ビューアは典型的な解像度のスクリーンにおいて、一貫性の無い符幹の幅を出力しようとします。このオプションは印刷結果の品質には目立って影響せず、PDF のファイル サイズを大きく増加させます。デフォルト:#f
。svg-woff
boolこのオプションは
svg
バックエンドで Web Open Format (WOFF) フォントを使うために必要となります。bool が#t
なら、ページ毎の SVG ファイルが全ページ分作られます。LilyPond 自身の音楽グリフを除き、フォントは埋め込まれません。そのため、テキストや歌詞の最適な描画を得るためには、SVG ビュアーにフォントが必要となります。SVG ビュアーが対応していないことがあるので、‘フォントエイリアス’ や ‘フォントリスト’ を使用しないことをお勧めします。デフォルト:#f
。verbose
饒舌レベル。これは読み込み専用のオプションで、設定しても効果はありません。
warning-as-error
boolbool が
#t
なら、すべての警告と ‘プログラミング エラー’ をエラーに変更します。デフォルト:#f
。
[ << lilypond を実行する ] | [Top][Contents][Index] | [ convert-ly を使ってファイルを更新する >> ] |
[ < LilyPond の高度なコマンド ライン オプション ] | [ Up : コマンド ラインの使用方法 ] | [ 再配置 > ] |
環境変数
lilypond
は以下の環境変数を認識します:
LILYPOND_DATADIR
これはデフォルトで参照するロケール メッセージとデータ ファイルがあるディレクトリを指定し、コンパイル時に定義されるか、実行時に動的に計算される場所を上書きします (再配置 を参照してください) 。このディレクトリは ly, ps, tex などのサブディレクトリを保持しているべきです。
LILYPOND_LOCALEDIR
ロケール固有のファイルが配置されているディレクトリを指定します。これは
LILYPOND_DATADIR
から派生した値を上書きします。LILYPOND_RELOCDIR
再配置ファイルが配置されているディレクトリを指定します。これは
lilypond
バイナリの場所から派生した値を上書きします。LANG
stdout
およびstderr
に送信される LilyPond データ、たとえば、進捗レポート、警告メッセージ、デバッグ出力などの言語を選択します。例:LANG=de
LILYPOND_LOGLEVEL
デフォルトのログレベル。明示的にログレベルが指定されずに LilyPond が呼び出された場合 (すなわち --loglevel コマンド ライン オプションが指定されなかった場合)、この値が使用されます。
LILYPOND_GC_YIELD
メモリ管理を調節する変数 (単位はパーセント) です。大きな値は LilyPond に多くのメモリ使用を許し、小さな値だと CPU 使用時間が長くなります。デフォルト値は
70
です。 この変数を使ってメモリ使用量とパフォーマンスを調節することができます。これはメモリ管理の振る舞いを調整するパーセント値です。高い値にするとプログラムはより多くのメモリを使用し、低い値にするとより多くの CPU 時間を使用します。デフォルト値は70
です。
[ << lilypond を実行する ] | [Top][Contents][Index] | [ convert-ly を使ってファイルを更新する >> ] |
[ < 環境変数 ] | [ Up : コマンド ラインの使用方法 ] | [ 再配置ファイル > ] |
再配置
Unix の世界のほとんどのプログラムは、コンパイル前の構成時に決定されるデフォルト ディレクトリを使用します。 LilyPond も例外ではありません。たとえば、標準的なインストールでは、lilypond バイナリが /usr/bin に配置され、LilyPond に固有のすべてのファイルが /usr/share/lilypond/2.25.20/ のサブディレクトリに配置されます (現在のバージョンが 2.25.20 であると仮定すると) 。
このアプローチは、手動コンパイルや標準のパッケージ マネージャーが付属するプラットフォームでは正常に機能しますが、そのようなマネージャーが一般的でないか、デフォルトで使用されないプラットフォームでは問題を引き起こす可能性があります。このようなプラットフォームの典型的な例は、ユーザーがアプリケーション バンドルをどこにでもインストールできると期待している Windows と MacOS です。
この問題の一般的な解決策は再配置サポートです。データファイルへのハードコーディングされたパスを使用する代わりに、必要なサポートファイルの場所が実行時に実行されたバイナリに対して相対的に計算されます。
再配置ファイル | ||
再配置アルゴリズム |
[ << lilypond を実行する ] | [Top][Contents][Index] | [ convert-ly を使ってファイルを更新する >> ] |
[ < 再配置 ] | [ Up : 再配置 ] | [ 再配置アルゴリズム > ] |
再配置ファイル
実行時の構成には、実際には別のメカニズムがあります。
LilyPond は、外部プログラムとライブラリ、特にシステムフォントを見つけるための ‘FontConfig’ 、
Scheme ファイルを処理するための ‘Guile’ ライブラリ、
PS データを PDF ファイルに変換するための gs
プログラムにそれぞれ大きく依存しています。それらのすべては、関連するデータファイルを見つけるためにも構成する必要があります。これを行うために、lilypond
プログラムは外部ライブラリとプログラムを制御する環境変数を操作するために、
relocate というディレクトリ(存在する場合。下のこのディレクトリが検索される場所を参照してください)
内のすべてのファイルを解析します。このような再配置ファイルのフォーマットは単純です。各行には構文があります
command key=value
空の行は無視されます。
command ディレクティブは次のいずれかです。
set
環境変数 key を無条件に value にセットします。 これは以前に設定された値を上書きします。
set?
key がまだ定義されていない場合にのみ、環境変数 key を value にセットします。つまり、以前に設定された値を上書きしません。
setdir
value がディレクトリの場合、無条件に環境変数 key を value にセットします。それ以外の場合は、警告を発します。
setfile
value がファイルの場合、無条件に環境変数 key を value にセットします。それ以外の場合は、警告を発します。
prependdir
環境変数 key 内のディレクトリのリストにディレクトリ value を追加します。 key が存在しない場合は作成されます。
(先頭のドル記号でマークされた) 環境変数は value で許可され、ディレクティブが実行される前に展開されます。
以下は、GUB から取得した再配置ファイル エントリの 2 つの例です を参照してください) 。
set? FONTCONFIG_FILE=$INSTALLER_PREFIX/etc/fonts/fonts.conf prependdir GUILE_LOAD_PATH=$INSTALLER_PREFIX/share/guile/1.8
relocate ディレクトリ内のファイルの解析順序は任意であるため、再配置ファイルでは、複数の行で同じ環境変数を設定することを避ける必要があります。
[ << lilypond を実行する ] | [Top][Contents][Index] | [ convert-ly を使ってファイルを更新する >> ] |
[ < 再配置ファイル ] | [ Up : 再配置 ] | [ chroot jail 環境で LilyPond を実行する > ] |
再配置アルゴリズム
LilyPond は、次のアルゴリズムを使用してデータファイルを検索します。
- 現在実行されている
lilypond
バイナリが配置されているディレクトリを計算します。これをbindir
としましょう。 (内部) 環境変数INSTALLER_PREFIX
を bindir/.. (つまり、bindir
の親ディレクトリ) にセットします。 - 環境変数
LILYPOND_DATADIR
を確認します。セットされている場合は、その値を LilyPond のデータ ディレクトリdatadir
に使用します。それ以外の場合は、$INSTALLER_PREFIX/share/lilypond/version (version は現在の LilyPond バージョンです) または $INSTALLER_PREFIX/share/lilypond/current を使用します。 - 環境変数
LILYPOND_LOCALEDIR
を確認します。セットされている場合は、その値を LilyPond のロケール データ ディレクトリlocaledir
に使用します。それ以外の場合は、$INSTALLER_PREFIX/share/locale を使用します。 - 環境変数
LILYPOND_RELOCDIR
を確認します。セットされている場合は、その値を LilyPond の再配置ファイルのディレクトリrelocdir
に使用します。それ以外の場合は、$INSTALLER_PREFIX/etc/relocate を使用します。 -
datadir
が存在しない場合は、代わりにコンパイル時の値を使用します。localedir
についても同様です (ただし、relocdir
に関しては無意味なので、同様ではありません) 。 -
relocdir
が存在する場合は、再配置ファイル の説明に従って、このディレクトリ内のすべてのファイルを処理します。
[ << lilypond を実行する ] | [Top][Contents][Index] | [ convert-ly を使ってファイルを更新する >> ] |
[ < 再配置アルゴリズム ] | [ Up : コマンド ラインの使用方法 ] | [ エラー メッセージ > ] |
chroot jail 環境で LilyPond を実行する
LilyPond を chroot jail 環境で実行させるようサーバをセットアップすることは複雑な作業です。以下にステップをリスト アップします。各ステップの中にある例は Ubuntu GNU/Linux 用であり、sudo
の使用が必要となるかもしれません。
- 必要なパッケージをインストールします: LilyPond, Ghostscript, それに ImageMagick。
-
lily
という名前のユーザを作成します:adduser lily
このコマンドはユーザ
lily
のためにホーム フォルダ (/home/lily
) と新しいグループも作成します。 - ユーザ
lily
のホーム フォルダで、独立したファイルシステムとして使用するファイルを作成します:dd if=/dev/zero of=/home/lily/loopfile bs=1k count= 200000
このコマンドは jail ファイルシステムとして使用する 200MB のファイルを作成します。
- ループ デバイスを作成し、ファイルシステムを作ってそれをマウントし、それからユーザ
lily
が書き込めるフォルダを作成します:mkdir /mnt/lilyloop losetup /dev/loop0 /home/lily/loopfile mkfs -t ext3 /dev/loop0 200000 mount -t ext3 /dev/loop0 /mnt/lilyloop mkdir /mnt/lilyloop/lilyhome chown lily /mnt/lilyloop/lilyhome
- サーバのコンフィグレーションで、JAIL は
/mnt/lilyloop
となり、DIR は/lilyhome
となります。 - 以下に示すサンプル スクリプトのように必要なファイルをコピーして
jail の中に大きなディレクトリ ツリーを作成します。
sed
を使うことで必要な実行形式ファイルをコピーすることができます:for i in "/usr/local/lilypond/usr/bin/lilypond" "/bin/sh" "/usr/bin/; \ do ldd $i | sed 's/.*=> \/\(.*\/\)\([^(]*\).*/mkdir -p \1 \&\& \ cp -L \/\1\2 \1\2/' | sed 's/\t\/\(.*\/\)\(.*\) (.*)$/mkdir -p \ \1 \&\& cp -L \/\1\2 \1\2/' | sed '/.*=>.*/d'; done
32-bit Ubuntu 8.04 用のスクリプト例
#!/bin/sh ## defaults set here username=lily home=/home loopdevice=/dev/loop0 jaildir=/mnt/lilyloop # the prefix (without the leading slash!) lilyprefix=usr/local # the directory where lilypond is installed on the system lilydir=/$lilyprefix/lilypond/ userhome=$home/$username loopfile=$userhome/loopfile adduser $username dd if=/dev/zero of=$loopfile bs=1k count=200000 mkdir $jaildir losetup $loopdevice $loopfile mkfs -t ext3 $loopdevice 200000 mount -t ext3 $loopdevice $jaildir mkdir $jaildir/lilyhome chown $username $jaildir/lilyhome cd $jaildir mkdir -p bin usr/bin usr/share usr/lib usr/share/fonts $lilyprefix tmp chmod a+w tmp cp -r -L $lilydir $lilyprefix cp -L /bin/sh /bin/rm bin cp -L /usr/bin/convert /usr/bin/gs usr/bin cp -L /usr/share/fonts/truetype usr/share/fonts # Now the library copying magic for i in "$lilydir/usr/bin/lilypond" "$lilydir/usr/bin/guile" "/bin/sh" \ "/bin/rm" "/usr/bin/gs" "/usr/bin/convert"; do ldd $i | sed 's/.*=> \ \/\(.*\/\)\([^(]*\).*/mkdir -p \1 \&\& cp -L \/\1\2 \1\2/' | sed \ 's/\t\/\(.*\/\)\(.*\) (.*)$/mkdir -p \1 \&\& cp -L \/\1\2 \1\2/' \ | sed '/.*=>.*/d'; done | sh -s # The shared files for Ghostscript... cp -L -r /usr/share/ghostscript usr/share # The shared files for ImageMagick cp -L -r /usr/lib/ImageMagick* usr/lib ### Now, assuming that you have test.ly in /mnt/lilyloop/lilyhome, ### you should be able to run: ### Note that /$lilyprefix/bin/lilypond is a script, which sets the ### LD_LIBRARY_PATH - this is crucial /$lilyprefix/bin/lilypond -jlily,lily,/mnt/lilyloop,/lilyhome test.ly
[ << lilypond を実行する ] | [Top][Contents][Index] | [ convert-ly を使ってファイルを更新する >> ] |
[ < chroot jail 環境で LilyPond を実行する ] | [ Up : lilypond を実行する ] | [ 一般的なエラー > ] |
1.3 エラー メッセージ
ファイルのコンパイルの最中にはさまざまなエラー メッセージが表示される可能性があります。
- Warning ¶
何か疑わしいことがあります。あなたが何か普通でないことをリクエストしている場合は、そのメッセージを理解して、それを無視することができます。しかしながら、Warning は通常、入力ファイルに何か問題があることを示しています。
- Error
何か明らかに問題があります。カレントの処理ステップ (構文解析、構文解釈、フォーマット) は終了され、次のステップは飛ばされます。
- Fatal error ¶
-
何か明らかに問題があり、LilyPond はコンパイルを続けられません。これが起きることは稀です。これが起こるのはたいてい、フォントのインストールに問題があるためです。
- Scheme error ¶
-
Scheme コードの実行中に発生するこのエラーは Scheme インタプリタによって引き起こされます。冗長オプション (-V または --verbose) 付きで実行している場合、問題となっている関数呼び出しの呼び出し追跡が表示されます。
- Programming error ¶
内部的な矛盾があります。このエラー メッセージはプログラマとデバッガを助けることを意図したものです。通常、それらは無視できます。時々、それらは非常に大きなメッセージとなり、他の出力を見えにくくします。
- Aborted (core dumped)
これは、プログラムをクラッシュさせる深刻なプログラミング エラーを示しています。そのようなエラーは決定的なものだと考えられます。あなたがそのようなエラーでつまずいた場合、バグ レポートを送ってください。
警告とエラーを入力ファイルのある部分にリンクさせることが可能な場合、エラー メッセージは以下のような形式になります:
filename:lineno:columnno: message offending input line
エラーが見つかった場所を示すために問題のある行に改行が挿入されます。例えば:
test.ly:2:19: error: not a duration: 5 { c'4 e' 5 g' }
これらの位置は LilyPond が警告やエラーが発生した位置を最善を尽くして推測したものですが、(ごく当たり前のことですが) 警告とエラーは何か予期しないことが起こったときに発生するものです。入力ファイルの示された行にエラーを見つけることができない場合は、示された位置の 1 行か 2 行上をチェックしてみてください。
診断は多くの処理段階のあらゆる時点で発生し得ることに注意してください。例えば、入力が複数回処理される(つまり、MIDI とレイアウト出力)または同じ音楽変数がコンテキストで使われると、同じメッセージが何回か現れることがあります。
エラーについての更なる情報が 一般的なエラー で提供されています。
[ << lilypond を実行する ] | [Top][Contents][Index] | [ convert-ly を使ってファイルを更新する >> ] |
[ < エラー メッセージ ] | [ Up : lilypond を実行する ] | [ 楽譜がページからはみ出る > ] |
1.4 一般的なエラー
以下で説明するエラーがしばしば発生しますが、その原因は明白でなかったり、見つけにくかったりします。目を通しておくと、それらのエラーに対処しやすくなります。
楽譜がページからはみ出る | ||
余計な譜が表示される | ||
エラー メッセージ Unbound variable % | ||
エラー メッセージ FT_Get_Glyph_Name | ||
警告 staff affinities should only decrease | ||
エラー メッセージ unexpected \new | ||
警告 this voice needs a \voiceXx or \shiftXx setting |
[ << lilypond を実行する ] | [Top][Contents][Index] | [ convert-ly を使ってファイルを更新する >> ] |
[ < 一般的なエラー ] | [ Up : 一般的なエラー ] | [ 余計な譜が表示される > ] |
楽譜がページからはみ出る
楽譜がページの右マージンを越えてはみ出る、あるいは過度に密集するのは、ほぼ間違いなく音符の演奏時間に誤りがあり、小節の最後の音符が小節線を越えてしまうためです。ある小節の最後の音符が自動的に挿入される小節線の所で終わらなくても無効ではありません。なぜなら、その音符は次の小節に持ち越されるためです。しかしながら、そのような持ち越しが発生する小節が長く続くと、楽譜は密集して表示されたり、ページからはみ出たりします。ページからはみ出るのは、自動改行を挿入できるのは正しく終了する小節 (その小節のすべての音符が小節の中で終了しています) の後ろだけだからです。
Note: 誤った演奏時間は改行を抑制し、結果として楽譜が過度に密集したり、c ページからはみ出たりする可能性が生じます。
小節チェックを使用していれば、誤った演奏時間を簡単に見つけることができます。小節と小節番号のチェック を参照してください。
あなたがそのような音符が持ち越される小節を続けることを意図しているのであれば、改行させたい場所に不可視の小節線を挿入する必要があります。詳細は 小節線 を参照してください。
[ << lilypond を実行する ] | [Top][Contents][Index] | [ convert-ly を使ってファイルを更新する >> ] |
[ < 楽譜がページからはみ出る ] | [ Up : 一般的なエラー ] | [ エラー メッセージ Unbound variable % > ] |
余計な譜が表示される
コンテキストが \new
や \context
で明示的に作成されていない場合、既存のコンテキストには適用できないコマンドに遭遇した時点で暗黙的に作成されます。単純な楽譜では、コンテキストの自動作成は有用であり、LilyPond マニュアルのほとんどの例はこの手法を用いています。しかしながら、コンテキストの暗黙的な作成はしばしば予期しない譜や楽譜を発生させてしまいます。例えば、以下のコードは後に続く譜の中にあるすべての符頭を赤にすることを意図していますが、結果は 2 つの譜が表示され、下の譜の符頭の色はデフォルトの黒のままとなります。
\override Staff.NoteHead.color = #red \new Staff { a' }
これは、(符頭色の) オーバライドが処理される時に
Staff
コンテキストが存在していないため、Staff
コンテキストが暗黙的に作成され、そのコンテキストにオーバライドが適用されるからです。その後に \new Staff
コマンドによりもう 1 つ別の Staff
コンテキストが作成され、そこに音符が配置されます。すべての符頭を赤にする正しいコードは以下のようになります:
\new Staff { \override Staff.NoteHead.color = #red a' }
[ << lilypond を実行する ] | [Top][Contents][Index] | [ convert-ly を使ってファイルを更新する >> ] |
[ < 余計な譜が表示される ] | [ Up : 一般的なエラー ] | [ エラー メッセージ FT_Get_Glyph_Name > ] |
エラー メッセージ Unbound variable %
このエラー メッセージは、Scheme 形式ではなく LilyPond 形式のコメントを含む Scheme ルーチンが呼び出されるたびに、コンソール出力またはログ ファイルの最後に表示されます。
LilyPond 形式のコメントはパーセント記号 (%
) で始まり、Scheme ルーチンの中で使うことはできません。Scheme 形式のコメントはセミコロン (;
) で始まります。
[ << lilypond を実行する ] | [Top][Contents][Index] | [ convert-ly を使ってファイルを更新する >> ] |
[ < エラー メッセージ Unbound variable % ] | [ Up : 一般的なエラー ] | [ 警告 staff affinities should only decrease > ] |
エラー メッセージ FT_Get_Glyph_Name
入力ファイルが非 ASCII キャラクタを保持していて、UTF-8 エンコードで保存されていない場合、このエラー メッセージがコンソール出力やログ ファイルに表示されます。詳細は、 テキスト エンコーディング を参照してください。
[ << lilypond を実行する ] | [Top][Contents][Index] | [ convert-ly を使ってファイルを更新する >> ] |
[ < エラー メッセージ FT_Get_Glyph_Name ] | [ Up : 一般的なエラー ] | [ エラー メッセージ unexpected \new > ] |
警告 staff affinities should only decrease
この警告は、譜刻された出力の中に譜が無い場合に表示されます。例えば、リード譜に ChordName
コンテキストと Lyrics
コンテキストしか無い場合です。この警告は、入力の始めに以下を挿入することで譜として振舞うコンテキストを作ることで回避できます:
\override VerticalAxisGroup.staff-affinity = ##f
詳細は システム内部の可変な垂直方向のスペース の “譜ではない行のスペース” を参照してください。
[ << lilypond を実行する ] | [Top][Contents][Index] | [ convert-ly を使ってファイルを更新する >> ] |
[ < 警告 staff affinities should only decrease ] | [ Up : 一般的なエラー ] | [ 警告 this voice needs a \voiceXx or \shiftXx setting > ] |
エラー メッセージ unexpected \new
\score
ブロックは 1 つの 音楽表記を含む必要があります。
\new Staff
や \new StaffGroup
、その他 \new
で生成される同様のコンテキストが波括弧 { … }
や二重の山括弧 << … >>
で囲まれずに複数存在する場合に、エラー メッセージが出力されます。以下のようにです:
\score { % Invalid! Generates error: syntax error, unexpected \new \new Staff { … } \new Staff { … } }
エラーを避けるためには、全ての \new
文を波括弧あるいは二重の山括弧で囲んでください。
波括弧は連続的に \new
文を導入します:
\score { { \new Staff { a' a' a' a' } \new Staff { g' g' g' g' } } }
しかし、二重の山括弧を用いるべき場面の方が多いでしょう。譜は並行に (つまり、同時に) 導入されます:
\score { << \new Staff { a' a' a' a' } \new Staff { g' g' g' g' } >> }
[ << lilypond を実行する ] | [Top][Contents][Index] | [ convert-ly を使ってファイルを更新する >> ] |
[ < エラー メッセージ unexpected \new ] | [ Up : 一般的なエラー ] | [ convert-ly を使ってファイルを更新する > ] |
警告 this voice needs a \voiceXx
or \shiftXx
setting
2 つの異なるボイスが同じ向きの符幹を持ち、それらが同じタイミングで出現する時、ボイスにシフトが指定されていない場合に ‘warning: this voice needs a \voiceXx or \shiftXx setting’ という警告メッセージが LilyPond ファイルをコンパイルする際に出力されます。この警告は符幹が見えない場合 (例えば、全音符) にも、同じピッチにある短い方の音符の符幹が同じ向きにある場合、出力されます。
符幹の向きは、\voiceOne
などによって指定されない限り、譜の中での音符の位置に依存します。このとき、警告は符幹が同じ向きになってしまった場合 – つまり、複数のボイスが譜の上半分または下半分に固まってしまった場合 – にのみ出力されます。
\voiceOne
などを用いることによって、符幹の向きとシフトを指定したボイスで音符を配置した場合、これらの警告を回避することができます。
より大きいボイス番号を持つ音符 (例えば \voiceThree
など) は、音符列の衝突を避けるために自動的に移動します。符幹のある音符に対しては移動が目に見えますが、全音符は実際に符頭が衝突しない限り、あるいはボイスが自然な順番に配置されていない場合 (例えば \voiceThree
が
\voiceOne
よりも高い位置にある場合) ではない限り、移動しているように見えません。
参照
ボイスを明示的にインスタンス化する, 実際の音楽からの例, 単一譜の多声, 衝突の解決
[ << lilypond を実行する ] | [Top][Contents][Index] | [ lilypond-book を実行する >> ] |
[ < 警告 this voice needs a \voiceXx or \shiftXx setting ] | [ Up : Top ] | [ 何故構文は変更されるのか? > ] |
2 convert-ly
を使ってファイルを更新する
LilyPond が改善していくにつれ、いくつかのコマンドや関数の構文 (入力言語) は変わることがあります。このことによって、昔のバージョンの LilyPond で作られた入力ファイルを新しいバージョンで使う時に、予期しないエラーや警告、あるいは誤った出力を引き起こす可能性があります。
これに対処するため、このような昔の入力ファイルを新しい構文に更新する
convert-ly
コマンドを使うことができます。
2.1 何故構文は変更されるのか? | ||
2.2 convert-ly を呼び出す | ||
2.3 convert-ly のコマンド ライン オプション | ||
2.4 convert-ly の問題点 | ||
2.5 手動変換 | ||
2.6 複数のバージョンに対応するコードを書く |
[ << convert-ly を使ってファイルを更新する ] | [Top][Contents][Index] | [ lilypond-book を実行する >> ] |
[ < convert-ly を使ってファイルを更新する ] | [ Up : convert-ly を使ってファイルを更新する ] | [ convert-ly を呼び出す > ] |
2.1 何故構文は変更されるのか?
入力ファイルを読みやすく、書きやすくするために、しばしば構文は変更されますが、時により既存の関数が、新しい機能や改善に合わせて変更されることがあります。
これが実際にあった例です:
\paper
と \layout
のプロパティ名は全て、first-second-third
という形式で記述することになっています。しかしながら、バージョン 2.11.60 で printallheaders
プロパティがこの規則に従っていないことが判明しました。放置すべきでしょうか?
(新しいユーザはつじつまの合わない入力形式で混乱するでしょう。)
それとも、変更すべきでしょうか?
(既存の楽譜を持つユーザには煩わしいことです。)
このケースでは、プロパティ名を print-all-headers
に変更することを決断しました。そして、昔のユーザは convert-ly
コマンドによって既にある入力ファイルを自動的にアップデートすることができました。
しかし、convert-ly
はすべての変更を処理できるわけではありません。例えば、バージョン 2.4.2 以前の LilyPond では、アクセント文字と非英語文字を LaTeX の記法を用いて入力していました。
例えば Christmas のフランス語は No\"el
のように入力されていました。しかしながら、バージョン 2.6 以降の LilyPond では、特殊文字 ë
を UTF-8 文字として直接 LilyPond ファイルに入力しなければならなくなりました。convert-ly
はすべての LaTeX の特殊文字を UTF-8 文字に変換することはできません。手動で古い LilyPond 入力ファイルを更新する必要があります。
convert-ly
コマンドの変換ルールは、テキストのパターンマッチングと置換によって動作しています (つまり、与えられた入力ファイルの中で何が変更されたかの文脈を‘理解’してはいないということです)。
これはいくつかの結果をもたらします:
- 変換の信頼性は、それぞれの適用されるルールセットの品質と、対応する変更の複雑さ次第です。変換が、追加・手動の修正を要求することがあります。ですから万が一のために、変換前の入力ファイルは比較のために残しておくべきです。
- より新しいバージョンへの構文の変更のみが可能です: LilyPond の昔のバージョンへ変換するルールセットは存在しません。そのため、入力ファイルを更新するのは、昔のバージョンの LilyPond がもうメンテナンスされていない時に限るべきです。繰り返しますが、万が一のために変換前の入力ファイルは残しておくべきです。Git のようなバージョン管理システムを使うと、複数のバージョンの入力ファイルを管理するのに役立つかもしれません。
- LilyPond は処理の際、余計に配置された、あるいは省略された空白に左右されません。しかし、
convert-ly
で用いられるルールはコードのスタイルにいくらかの仮定を置く場合があります。ですから、正常な変換を行うために、LilyPond のマニュアルで用いられるスタイルに従うことを推奨します。特にマニュアル自体、すべての例がconvert-ly
コマンドで更新されています。
[ << convert-ly を使ってファイルを更新する ] | [Top][Contents][Index] | [ lilypond-book を実行する >> ] |
[ < 何故構文は変更されるのか? ] | [ Up : convert-ly を使ってファイルを更新する ] | [ convert-ly のコマンド ライン オプション > ] |
2.2 convert-ly
を呼び出す
convert-ly
コマンドは古いバージョンを検出するために入力ファイルの version
番号を使用します。たいていの場合、あなたの入力ファイルを更新するには、その入力ファイルを保持しているディレクトリで以下を実行するだけで十分です:
convert-ly -e myfile.ly
これにより、myfile.ly
はその場で更新され、オリジナル ファイルは myfile.ly~
に名前が変更されて保存されます。更新された入力ファイルの \version
番号も、必要な構文の更新に合わせて変更されます。
convert-ly
コマンドが実行される時、変換が行われるバージョンの番号を出力します。バージョン番号が出力されなかった場合、そのファイルは既に更新されており、最新の LilyPond 構文を使用しています。
Note: LilyPond の新しいバージョンごとに、新しい convert-ly
コマンドが作られます。しかし、全てのバージョンがその前のバージョンの入力ファイルから構文の変更を必要とするわけではありません。つまり
convert-ly
コマンドは、入力ファイルをその時点の最新の構文にまでしか変換しないということであり、逆に言えば、変換されたファイルの
\version
番号が convert-ly
コマンド自体のバージョンより前のバージョンになる場合もあるということです。
単一のディレクトリにある全ての入力ファイルを変換するには、以下のようにします:
convert-ly -e *.ly
Linux や MacOS X のユーザーは、適当なターミナルからこのコマンドを実行できますが、MacOS X のユーザーは、メニューの
Compile > Update syntax
からも直接コマンドを実行できます。
Windows ユーザーがコマンド ラインを用いる場合はこのようになります:
convert-ly.py -e *.ly
これを、コマンド プロンプト
から実行します。コマンド プロンプト
は通常、スタート > アクセサリ > コマンド プロンプト
にありますが、Windows 8 ユーザーであるなら、検索ウィンドウに‘コマンド プロンプト’と入力することでも実行できます。
複数のサブディレクトリ内にある全ての入力ファイルを変換するには、以下のようにします:
find . -name '*.ly' -exec convert-ly -e '{}' \;
この例は、現在のディレクトリとその下にある全てのディレクトリに存在する入力ファイルを、再帰的に見つけ出し変換します。変換されたファイルはリネームされた元のファイルと同じディレクトリに配置されます。これは MacOS X でも動作するはずです (ターミナルからの実行のみとなりますが)。
Windows ユーザーは以下のようにします:
forfiles /s /M *.ly /c "cmd /c convert-ly.py -e @file"
代わりに、/p
オプションを使って、入力ファイルを含む全てのサブフォルダを保持したトップレベルのフォルダを指定することができます:
forfiles /s /p C:\Documents\MyScores /M *.ly /c "cmd /c convert-ly.py -e @file"
トップレベルのフォルダへのパスにスペースが含まれる場合には、パス全体をダブルクォートで括る必要があります:
forfiles /s /p "C:\Documents\My Scores" /M *.ly /c "cmd /c convert-ly.py -e @file"
[ << convert-ly を使ってファイルを更新する ] | [Top][Contents][Index] | [ lilypond-book を実行する >> ] |
[ < convert-ly を呼び出す ] | [ Up : convert-ly を使ってファイルを更新する ] | [ convert-ly の問題点 > ] |
2.3 convert-ly
のコマンド ライン オプション
一般に、このプログラムは以下のように呼び出されます:
convert-ly [option]… filename…
以下のオプションを与えることができます:
-d, --diff-version-update
ファイルが実際に変更された場合にのみ
\version
を更新します。 これを指定した場合のバージョン番号は、最後に実際に変換が行われた後のバージョンに対応します。不安定版のバージョン番号は、ターゲットのバージョン番号を超えない限り、次の安定版のバージョン番号に上げられます。このオプションを指定しないと、最後の変換を行おうとしたバージョンに更新されます。-e, --edit
入力ファイルをその場で直接変換します。変換元のファイルは myfile.ly~ のように名前が変更されます。このバックアップファイルは、オペレーティングシステムによっては隠しファイルとして扱われているかもしれません。古い入力ファイルに
~
を付加する-e
を使わずに、更新されたファイルの名前を別に指定したい場合は、代わりに出力をリダイレクトすることができます:convert-ly myfile.ly > mynewfile.ly
Windows ユーザーは:
convert-ly.py myfile.ly > mynewfile.ly
-b, --backup-numbered
‘-e’ オプションと同時に用いた場合、前のバージョンのファイルが上書きされないように、バックアップファイルの名前に番号が付きます。バックアップファイルは、オペレーティングシステムによっては隠されているかもしれません。
-f, --from=from-patchlevel
変換元のバージョンをセットします。これがセットされていない場合、
convert-ly
は入力ファイルの中にあるversion
文字列を基に推測します。例: --from=2.10.25-h, --help
ヘルプ (使い方) を表示します。
-l loglevel, --loglevel=loglevel
出力の饒舌さを loglevel にセットします。取り得る値は、大文字で、
PROGRESS
(デフォルト),NONE
,WARN
,ERROR
, それにDEBUG
です。-n, --no-version
通常、
convert-ly
は\version
インジケータを出力に付け加えます。このオプションを指定すると、それを抑制します。-s, --show-rules
すべての変換を表示して、終了します。
-t, --to=to-patchlevel
変換先のバージョンを明示してセットします。明示されない場合は、デフォルトで最新バージョンにセットします。変換元のバージョンよりも高くなっている必要があります。
convert-ly --to=2.14.1 myfile.ly
texinfo ファイルの中にある LilyPond 断片を更新するには以下を使用してください:
convert-ly --from=… --to=… --no-version *.itely
2 つのバージョン間での LilyPond 構文の変更を調べるには、以下を使用してください:
convert-ly --from=… --to=… -s
[ << convert-ly を使ってファイルを更新する ] | [Top][Contents][Index] | [ lilypond-book を実行する >> ] |
[ < convert-ly のコマンド ライン オプション ] | [ Up : convert-ly を使ってファイルを更新する ] | [ 手動変換 > ] |
2.4 convert-ly
の問題点
Windows の ‘コマンド プロンプト’ ウィンドウからスペースを含むファイル名やパスを持つファイルに対してconvert-ly を実行する場合、入力ファイル名全体を 3 つ (!) のダブル クォートで囲む必要があります:
convert-ly """D:/My Scores/Ode.ly""" > "D:/My Scores/new Ode.ly"
convert-ly -e *.ly
コマンドが展開時に長くなりすぎて失敗する場合、convert-ly
コマンドをループさせてやります。以下の例は UNIX 用であり、カレント ディレクトリの中にあるすべての .ly
ファイルを更新します:
for f in *.ly; do convert-ly -e $f; done;
Windows の ‘コマンド プロンプト’ ウィンドウでの上の例に対応するコマンドは以下の通りです:
for %x in (*.ly) do convert-ly -e """%x"""
言語の変更がすべて処理されるわけではありません。指定できる出力オプションは 1 つだけです。自動的に Scheme と更新することと LilyPond の Scheme インタフェイスを更新することはまったく異なります。Scheme コードの調整は手動で行う覚悟でいてください。
[ << convert-ly を使ってファイルを更新する ] | [Top][Contents][Index] | [ lilypond-book を実行する >> ] |
[ < convert-ly の問題点 ] | [ Up : convert-ly を使ってファイルを更新する ] | [ 複数のバージョンに対応するコードを書く > ] |
2.5 手動変換
理論的には、convert-ly
のようなプログラムはすべての構文変更を処理できます。
After all, a computer program interprets the old
version and the new version, so another computer program can
translate one file into another2.
しかしながら、LilyPond プロジェクトの資源には限りがあり、すべての変換を自動化することはできません。以下は既知の問題のリストです。
1.6->2.0: Doesn't always convert figured bass correctly, specifically things like {< >}. Mats' comment on working around this: To be able to run convert-ly on it, I first replaced all occurrences of '{<' to some dummy like '{#' and similarly I replaced '>}' with '&}'. After the conversion, I could then change back from '{ #' to '{ <' and from '& }' to '> }'. Doesn't convert all text markup correctly. In the old markup syntax, it was possible to group a number of markup commands together within parentheses, e.g. -#'((bold italic) "string") This will incorrectly be converted into -\markup{{\bold italic} "string"} instead of the correct -\markup{\bold \italic "string"} 2.0->2.2: Doesn't handle \partCombine Doesn't do \addlyrics => \lyricsto, this breaks some scores with multiple stanzas. 2.0->2.4: \magnify isn't changed to \fontsize. - \magnify #m => \fontsize #f, where f = 6ln(m)/ln(2) remove-tag isn't changed. - \applyMusic #(remove-tag '. . .) => \keepWithTag #'. . . first-page-number isn't changed. - first-page-number no => print-first-page-number = ##f Line breaks in header strings aren't converted. - \\\\ as line break in \header strings => \markup \center-align < "First Line" "Second Line" > Crescendo and decrescendo terminators aren't converted. - \rced => \! - \rc => \! 2.2->2.4: \turnOff (used in \set Staff.VoltaBracket = \turnOff) is not properly converted. 2.4.2->2.5.9 \markup{ \center-align <{ ... }> } should be converted to: \markup{ \center-align {\line { ... }} } but now, \line is missing. 2.4->2.6 Special LaTeX characters such as $~$ in text are not converted to UTF8. 2.8 \score{} must now begin with a music expression. Anything else (particularly \header{}) must come after the music.
[ << convert-ly を使ってファイルを更新する ] | [Top][Contents][Index] | [ lilypond-book を実行する >> ] |
[ < 手動変換 ] | [ Up : convert-ly を使ってファイルを更新する ] | [ lilypond-book を実行する > ] |
2.6 複数のバージョンに対応するコードを書く
いくつかの場面で、特にライブラリのコードを書く場合、破壊的な構文変更を含んだ複数の LilyPond バージョンをサポートすることは望ましいでしょう。これは、バージョンによって変更が必要な部分を、現在実行されている
LilyPond のバージョンで分岐する条件文で囲むことで実現できます。Scheme 関数 ly:version?
は比較演算子 op と、比較の対象となるバージョンを 3 つまでの整数のリストで表現した ver を引数に取ります。
整数の数が足りない場合は無視されます。例えば、'(2 20)
は全ての 2.20 の系列のバージョンと等しくなります。このような表記が可能です:
#(cond ((ly:version? > '(2 20)) (ly:message "This is code to run for LilyPond after 2.20")) ((ly:version? = '(2 19 57)) (ly:message "This will only be executed with LilyPond 2.19.57")) (else (ly:message "This will be executed in any other version")))
通常、これは (訳注: バージョンによって) 別の構文が使えるようにするためにライブラリ関数に組み込まれますが、以下の例のように、比較を直接音楽の中に用いることもできます:
{ c' d' e' f' #(if (ly:version? = '(2 21)) #{ \override NoteHead.color = #red #} #{ \override NoteHead.color = #blue #}) g' a' b' c'' }
注意: この関数は LilyPond 2.19.57 で導入されました。そのため、それより古いバージョンと比較することはできません。
[ << convert-ly を使ってファイルを更新する ] | [Top][Contents][Index] | [ 外部プログラム >> ] |
[ < 複数のバージョンに対応するコードを書く ] | [ Up : Top ] | [ 音楽学のドキュメントの例 > ] |
3 lilypond-book
を実行する
ドキュメントに楽譜の画像を追加したければ、他のタイプの画像を追加するのと同じ方法で追加することができます。ドキュメントとは別に画像を作成して、PostScript 出力や PNG 画像として保存して、LaTeX や HTML ドキュメントに組み込みます。
lilypond-book
はこの処理を自動で行うための手段です:
このプログラムはドキュメントから楽譜のコード断片を抽出して、それらに対して lilypond
を実行して、楽譜のコード断片を画像で置き換えたドキュメントを出力します。楽譜の線の太さやフォント サイズはドキュメントのレイアウトに調和するよう調節されます。
lilypond-book
は lilypond
とは別のプログラムであり、コマンド ラインで実行されます。更なる情報は コマンド ラインの使用方法 を参照してください。Windows や Mac OS X のコマンド ラインを用いて lilypond-book
を実行しようとした際に問題があるようなら、Windows や MacOS X
を参照してください。
この処理は LaTeX, HTML, Texinfo, または DocBook のドキュメントに適用することができます。
3.1 音楽学のドキュメントの例 | ||
3.2 楽譜とテキストを統合する | ||
3.3 楽譜断片オプション | ||
3.4 lilypond-book を呼び出す | ||
3.5 ファイル拡張子 | ||
3.6 lilypond-book テンプレート | ||
3.7 目次を共有する | ||
3.8 テキストと楽譜を組み合わせる他の方法 |
[ << lilypond-book を実行する ] | [Top][Contents][Index] | [ 外部プログラム >> ] |
[ < lilypond-book を実行する ] | [ Up : lilypond-book を実行する ] | [ 楽譜とテキストを統合する > ] |
3.1 音楽学のドキュメントの例
テキストのなかには楽譜の例を保持しているものがあります。そのようなテキストには、音楽学の専門書、歌集、このドキュメントのようなマニュアルがあります。そのようなテキストを手作業で作成することができます – PostScript 画像をワープロにインポートするといったようにです。しかしながら、HTML, LaTeX, Texinfo, それに DocBook ドキュメントの場合は、作業量を減らすための自動処理を利用することができます。
lilypond-book
と呼ばれるスクリプトは楽譜の断片を抽出して、それらをフォーマットして、得られた楽譜をドキュメントに戻します。LaTeX に対するちょっとした使用例を示します。この例には説明文も含まれていますので、それ以上コメントすることはしません。
入力
\documentclass[a4paper]{article} \begin{document} \verb+lilypond-book+ のドキュメントでは自由に楽譜とテキストを 組み合わせることができます。 例えば、以下のように: \begin{lilypond} \relative { c'2 e2 \tuplet 3/2 { f8 a b } a2 e4 } \end{lilypond} オプションは角括弧の中に配置します。 \begin{lilypond}[fragment,quote,staffsize=26,verbatim] c'4 f16 \end{lilypond} 大きな楽譜例は別のファイルに配置して、\verb+\lilypondfile+ で インポートすることができます。 \lilypondfile[quote,noindent]{screech-and-boink.ly} (必要があれば、@file{screech-and-boink.ly} をこのファイルと同じディレクトリ にある任意の @file{.ly} に置き換えてください。) \end{document}
処理
上記のコードを lilybook.lytex というファイル名で保存して、ターミナルで以下を実行します:
lilypond-book --output=out --pdf lilybook.lytex
lilypond-book (GNU LilyPond) 2.25.20
Reading lilybook.lytex...
…lots of stuff deleted…
Compiling lilybook.tex...
cd out
pdflatex lilybook
…lots of stuff deleted…
xpdf lilybook
(xpdf
をお好みの PDF ビューアに置き換えてください)
lilypond-book
と latex
を実行すると多くの一時ファイルが作成されて、作業ディレクトリを散らかします。散らかされることを防ぐには --output=dir オプションを使います。このオプションを指定すると、一時ファイルはサブディレクトリ dir
に作成されます。
以下に上記の LaTeX 例の結果を示します。3これでこのチュートリアル セクションを終わります。
出力
lilypond-book
のドキュメントでは自由に楽譜とテキストを
組み合わせることができます。
例えば、以下のように:
オプションは角括弧の中に配置します。
c'4 f16
大きな楽譜例は別のファイルに配置して、\lilypondfile
で
インポートすることができます。
デフォルトあるいはカスタムの tagline
が必要であれば、
楽譜コード断片全体を \book { }
構造で囲んでください。
\book{ \header{ title = "A scale in LilyPond" } \relative { c' d e f g a b c } }
[ << lilypond-book を実行する ] | [Top][Contents][Index] | [ 外部プログラム >> ] |
[ < 音楽学のドキュメントの例 ] | [ Up : lilypond-book を実行する ] | [ LaTeX > ] |
3.2 楽譜とテキストを統合する
LilyPond をさまざまな出力フォーマットと統合する方法を説明します。
3.2.1 LaTeX | ||
3.2.2 Texinfo | ||
3.2.3 HTML | ||
3.2.4 DocBook |
[ << lilypond-book を実行する ] | [Top][Contents][Index] | [ 外部プログラム >> ] |
[ < 楽譜とテキストを統合する ] | [ Up : 楽譜とテキストを統合する ] | [ Texinfo > ] |
3.2.1 LaTeX
LaTeX は物理学や化学等の出版のデファクト スタンダードです。LaTeX は TeX 植字エンジン上に構築され、最高品位の活版印刷術を提供します。
LaTeX の使い方についての概要は The Not So Short Introduction to LaTeX を参照してください。
lilypond-book
は楽譜を LaTeX ファイルに組み込むために以下のコマンドと環境を提供します:
-
\lilypond{…}
コマンド: ここに直接短い lilypond コードを入力することができます -
\begin{lilypond}…\end{lilypond}
環境: ここに長い lilypond コードを入力することができます -
\lilypondfile{…}
コマンド: このコマンドで lilypond ファイルを挿入することができます -
\musicxmlfile{…}
コマンド: このコマンドで MusicXML ファイルを挿入することができます。挿入されたファイルはmusicxml2ly
とlilypond
で処理されます
入力ファイルの中では、楽譜は以下のコマンドのいずれかで特定されます:
\begin{lilypond}[options,go,here] YOUR LILYPOND CODE \end{lilypond} \lilypond[options,go,here]{ YOUR LILYPOND CODE } \lilypondfile[options,go,here]{filename} \musicxmlfile[options,go,here]{filename}
さらに、\lilypondversion
は lilypond のバージョン番号を表示します。lilypond-book
を実行して得られたファイルを更に LaTeX で処理することができます。
例をいくつか挙げます。以下の lilypond
環境
\begin{lilypond}[quote,fragment,staffsize=26] c' d' e' f' g'2 g'2 \end{lilypond}
これは以下を作り出します
以下の短いバージョン
\lilypond[quote,fragment,staffsize=11]{<c' e' g'>}
これは以下を作り出します
今のところ \lilypond{}
の中で {
や }
を記述することはできないため、このコマンドは fragment
オプションを指定した場合にのみ機能します。
楽譜のデフォルトの行幅は、ドキュメント前文
– \begin{document}
より前の部分 –
のコマンドを検証することにより調節されます。lilypond-book
コマンドはそれらのコマンドを LaTeX に送ってテキストの幅を調べます。その後、楽譜断片の行幅はそのテキスト幅に調節されます。試行錯誤なアルゴリズムは容易に失敗する可能性があります
– そのような場合、line-width
楽譜断片オプションを使用する必要があります。
以下のマクロがユーザによって定義されている場合、各楽譜断片はそれらのマクロを呼び出します:
-
\preLilyPondExample
は楽譜断片の処理が始まる前に呼び出されます。 -
\postLilyPondExample
は楽譜断片の処理が終わった後に呼び出されます。 -
\betweenLilyPondSystem[1]
は、lilypond-book
が楽譜断片をいくつかの PostScript ファイルに分けて出力する場合に、ある段と次の段の間で呼び出されます。このマクロはパラメータを 1 つ取るように定義する必要があり、何段数目の処理が終わったらマクロが動作を始めるかを指定する数を渡します。デフォルトでは\linebreak
を挿入するだけです。
Selected Snippets
楽譜要素 (タイやスラー等) を断片の後に続くかのように表示することが有用な場合があります。これは譜を改行して、残りの LilyPond 出力を抑制することで実現できます。
LaTeX の中で \betweenLilyPondSystem
を定義して、必要な楽譜段数が出力された後の出力を抹消するようにします。\betweenLilyPondSystem
が最初に呼び出されるのは 最初の 段が処理された後なので、最初の段だけを残すことは簡単です。
\def\betweenLilyPondSystem#1{\endinput} \begin{lilypond}[fragment] c'1\( e'( c'~ \break c' d) e f\) \end{lilypond}
必要とする段数が多い場合、\endinput
の前で TeX 条件分岐を使う必要があります。以下の例で、‘2’ を必要とする段数に置き換えてください。
\def\betweenLilyPondSystem#1{ \ifnum#1<2\else\expandafter\endinput\fi }
(\endinput
は入力ファイルの処理をすぐに停止するため、\endinput
の呼び出しを \fi
実行後まで遅らせるために
\expandafter
を記述する必要があります。これにより \if
-\fi
節がバランスします。)
\betweenLilyPondSystem
の定義は TeX がカレントのグループ
(LaTeX 環境等) を終了するか、他の定義で上書きされる
(これは大抵の場合、ドキュメントの残りの部分に対する定義です)
まで効果を持つということを覚えておいてください。定義をリセットするには、LaTeX に以下を記述します:
\let\betweenLilyPondSystem\undefined
これを簡単にするには、以下の TeX マクロを定義して、
\def\onlyFirstNSystems#1{ \def\betweenLilyPondSystem##1{% \ifnum##1<#1\else\expandafter\endinput\fi} }
各楽譜断片の前に必要な段数を指定します。
\onlyFirstNSystems{3} \begin{lilypond}…\end{lilypond} \onlyFirstNSystems{1} \begin{lilypond}…\end{lilypond}
参照
LaTeX ドキュメント専用の lilypond-book
コマンド
オプションがあり、他にも知っておくべき細かなことがあります。lilypond-book
を呼び出す を参照してください。
[ << lilypond-book を実行する ] | [Top][Contents][Index] | [ 外部プログラム >> ] |
[ < LaTeX ] | [ Up : 楽譜とテキストを統合する ] | [ HTML > ] |
3.2.2 Texinfo
Texinfo は GNU プロジェクトのドキュメントのデフォルト フォーマットです。Texinfo ドキュメントの例の 1 つはこのマニュアルです。このマニュアルの HTML, PDF, それに Info 形式は Texinfo ドキュメントから生成されています。
lilypond-book
は楽譜を Texinfo ファイルに組み込むために以下のコマンドと環境を提供します:
-
@lilypond{…}
コマンド: ここに直接短い lilypond コードを入力することができます -
@lilypond…@end lilypond
環境: ここに長い lilypond コードを入力することができます -
@lilypondfile{…}
コマンド: このコマンドで lilypond ファイルを挿入することができます -
@musicxmlfile{…}
コマンド: このコマンドで MusicXML ファイルを挿入することができます。挿入されたファイルはmusicxml2ly
とlilypond
で処理されます
入力ファイルの中では、楽譜は以下のコマンドのいずれかで特定されます:
@lilypond[options,go,here] YOUR LILYPOND CODE @end lilypond @lilypond[options,go,here]{ YOUR LILYPOND CODE } @lilypondfile[options,go,here]{filename} @musicxmlfile[options,go,here]{filename}
さらに、@lilypondversion
は lilypond のバージョン番号を表示します。
lilypond-book
を実行して得られる Texinfo ファイル
(拡張子は .texi です) は HTML, Info, それに表示出力用の
@image
タグを保持しています。lilypond-book
は表示出力に対しては EPS と PDF 形式の楽譜を生成して、HTML と Info 出力に対しては PNG 形式の楽譜を生成します。
2 つの簡単な例を挙げます。以下の lilypond
環境
@lilypond[fragment] c' d' e' f' g'2 g' @end lilypond
これは以下を作り出します
以下の短いバージョン
@lilypond[fragment,staffsize=11]{<c' e' g'>}
これは以下を作り出します
LaTeX とは対照的に、@lilypond{…}
はインライン画像を生成しません。生成される画像は常に 1 つの段落を構成します。
[ << lilypond-book を実行する ] | [Top][Contents][Index] | [ 外部プログラム >> ] |
[ < Texinfo ] | [ Up : 楽譜とテキストを統合する ] | [ DocBook > ] |
3.2.3 HTML
lilypond-book
は楽譜を HTML ファイルに組み込むために以下のコマンドと環境を提供します:
-
<lilypond … />
コマンド: ここに直接短い lilypond コードを入力することができます -
<lilyond>…</lilypond>
環境: ここに長い lilypond コードを入力することができます -
<lilypondfile>…</lilypondfile>
コマンド: このコマンドで lilypond ファイルを挿入することができます -
<musicxmlfile>…</musicxmlfile>
コマンド: このコマンドで MusicXML ファイルを挿入することができます。挿入されたファイルはmusicxml2ly
とlilypond
で処理されます
入力ファイルの中では、楽譜は以下のコマンドのいずれかで特定されます:
<lilypond options go here> YOUR LILYPOND CODE </lilypond> <lilypond options go here: YOUR LILYPOND CODE /> <lilypondfile options go here>filename</lilypondfile> <musicxmlfile options go here>filename</musicxmlfile>
記述例を挙げます:
<lilypond fragment relative=2> \key c \minor c4 es g2 </lilypond>
上記のコードから lilypond-book
は楽譜断片に対する適切な画像タグを持つ HTML ファイルを作り出します:
インライン画像を得るには、<lilypond … />
を使います。以下のように、コロン :
でオプションと楽譜コードを区切ります:
Some music in <lilypond relative=2: a b c/> a line of text.
HTML ファイルとは別に記述した lilypond ファイルを組み込むには以下のようにします:
<lilypondfile option1 option2 …>filename</lilypondfile>
<musicxmlfile>
は <lilypondfile>
と同じ構文を使い、LilyPond ファイルではなく MusicXML ファイルを参照します。
lilypond
タグや lilypondfile
タグで使用するオプションのリストは、楽譜断片オプション を参照してください。
さらに、<lilypondversion/>
は lilypond のバージョン番号を表示します。
[ << lilypond-book を実行する ] | [Top][Contents][Index] | [ 外部プログラム >> ] |
[ < HTML ] | [ Up : 楽譜とテキストを統合する ] | [ 楽譜断片オプション > ] |
3.2.4 DocBook
LilyPond 断片を組み込む場合、DocBook ドキュメントとの適合を保つべきです。そうすることで、DocBook のエディタや検証機能等を使うことができます。そのため、カスタム タグは使わず、標準 DocBook 要素に基づく約束ごとだけを使います。
Common conventions
楽譜断片をインラインあるいはインラインではなく挿入するために、mediaobject
要素と inlinemediaobject
要素を使います。楽譜断片フォーマット オプションは常に最も内側の要素の role
プロパティの中に配置します (次のセクションを参照してください)。タグは DocBook エディタがコンテンツをきれいにフォーマットすることを可能にします。lilypond-book
で処理する DocBook ファイルの拡張子は
.lyxml にするべきです。
LilyPond ファイルを組み込む
これが最も簡単な方法です。組み込むファイルの拡張子は .ly にして、それを以下に示す構造で標準の imageobject
として挿入する必要があります:
<mediaobject> <imageobject> <imagedata fileref="music1.ly" role="printfilename" /> </imageobject> </mediaobject>
必要に応じて、最も外側の要素に mediaobject
または
inlinemediaobject
を使うことができるということに注意してください。
LilyPond コードを組み込む
programlisting
を用いることで、LilyPond コードを組み込むことができます。以下の構造を用いて、programlisting
の言語には lilypond
をセットします:
<inlinemediaobject> <textobject> <programlisting language="lilypond" role="fragment verbatim staffsize=16 ragged-right relative=2"> \context Staff \with { \remove Time_signature_engraver \remove Clef_engraver} { c4( fis) } </programlisting> </textobject> </inlinemediaobject>
最も外側の要素は mediaobject
または inlinemediaobject
であり、その中に programlisting
を保持する textobject
がありことが見て取れます。
DocBook ドキュメントを処理する
.lyxml ファイルに対して lilypond-book
を実行すると、拡張子が .xml の有効な DocBook ドキュメントが作成され、それを更に処理にかけることがでいます。dblatex を使うと、このドキュメントから自動的に PDF ファイルを作成することがでいます。公式 DocBook スタイルシートを用いることで HTML (HTML ヘルプ、JavaHelp 等)
を生成することが可能ですが、カスタマイズが必要かもしれません。
[ << lilypond-book を実行する ] | [Top][Contents][Index] | [ 外部プログラム >> ] |
[ < DocBook ] | [ Up : lilypond-book を実行する ] | [ lilypond-book を呼び出す > ] |
3.3 楽譜断片オプション
以下では、‘LilyPond コマンド’ は、これまでのセクションで説明した楽譜断片を作り出すために lilypond-book
によって処理される任意のコマンドを意味します。シンプルにするために、LaTeX 構文の LilyPond コマンドだけを示します。
オプション文字列は左から右の順で解析されるということに注意してください。あるオプションを複数指定した場合、最後のオプションが有効となります。
LilyPond コマンドで以下のオプションを使うことができます:
staffsize=ht
譜サイズを ht にセットします。単位はポイントです。
ragged-right
デフォルトの間隔を用いるため、行の右端が揃いません。つまり、LilyPond コード断片に
ragged-right = ##t
を追加します。明示的にnoragged-right
を指定しない限り、1 行の楽譜断片はデフォルトでは常に ragged-right で譜刻されます。noragged-right
楽譜断片が 1 行の場合に、譜の長さを行幅まで広げます。つまり、LilyPond コード断片に
ragged-right = ##f
を追加します。line-width
line-width=size\unit
行幅を size にセットします。unit は単位です。unit は以下の文字列のどれかです:
cm
,mm
,in
, あるいはpt
。このオプションは LilyPond 出力 (つまり、楽譜断片の譜の幅に) に影響を与えますが、テキスト レイアウトには影響を与えません。引数無しで使用した場合、行幅はデフォルト値にセットされます (試行錯誤的なアルゴリズムで算出される値です)。
line-width
オプションが指定されなかった場合、lilypond-book
はragged-right
オプションを使用しないlilypond
環境のデフォルトを推測しようと試みます。papersize=string
string は scm/paper.scm で定義されている紙面サイズ – つまり、
a5
,quarto
,11x17
等 – です。scm/paper.scm で定義されていない値は無視され、警告が発せられ、楽譜断片はデフォルトの
a4
サイズで譜刻されます。notime
拍子記号と小節線を譜刻しません。
fragment
lilypond-book
が常用コードを追加するので、\layout
,\score
等を入力する必要がなく、単に以下のように入力できます:c'4
nofragment
楽譜断片の LilyPond コードに補完コードを追加しません。これがデフォルトなので、通常、
nofragment
は不要です。indent=size\unit
楽譜の最初の段のインデントを size にセットします。unit は単位です。unit は以下の文字列のどれかです:
cm
,mm
,in
, あるいはpt
。このオプションは LilyPond に影響を与えますが、テキスト レイアウトには影響を与えません。noindent
楽譜の最初の段のインデントを 0 にセットします。このオプションは LilyPond に影響を与えますが、テキスト レイアウトには影響を与えません。これがデフォルトなので、通常、
noindent
は不要です。quote
楽譜の両端に 0.4in のインデントを挿入して、引用ブロックで囲みます。値 ‘0.4in’ は
exampleindent
オプションで制御することができます。exampleindent
quote
オプションが楽譜断片に挿入するインデントの量をセットします。relative
relative=n
相対オクターブ モードを使用します。デフォルトでは、音符はミドル C との相対関係で指定します。オプションで指定する整数の引数は開始音符のオクターブを指定します – デフォルトの
1
はミドル C です。relative
オプションはfragment
オプションがセットされている場合にのみ機能するため、relative
オプションがセットされるとソースの中の(no)fragment
オプション有無にかかわらずfragment
が自動的、暗黙的にセットされます。
LilyPond もそれ自体のドキュメントを作り出すのに lilypond-book
を使います。LilyPond のドキュメントを作るために、さらに細かな楽譜断片オプションが用意されています。
verbatim
LilyPond コマンドの引数をそのまま出力ファイルにコピーして、ブロックで囲み、その後に
intertext
オプションで与えられた任意のテキストが続きます (intertext
オプションはまだ実装されていません)。それから実際の楽譜が表示されます。段落の一部となっている\lilypond{}
でこのオプションを指定しても機能しません。lilypondfile
コマンドでverbatim
を使用した場合、ソース ファイルの一部だけをそのままコピーして囲むことができます。ソース ファイルが ‘begin verbatim’ (引用符を除く) という文字列を含むコメントを保持している場合、最後の ‘begin verbatim’ より後のソースが引用されます。同様に、‘end verbatim’ を含むコメントがあれば、ソースの引用は最初の ‘end verbatim’ の前で終了します。以下のソース ファイル例で、楽譜コードは相対モードで解釈されますが、ソースの引用にrelative
ブロックは表示されません。つまり、\relative { % begin verbatim c'4 e2 g4 f2 e % end verbatim }
上記のソースは以下のように引用されます。
c4 e2 g4 f2 e
ソースの引用の中にあるコメントと変数名を翻訳したけれども、ソース自体の中にあるコメントと変数名は翻訳したくない場合、環境変数
LYDOC_LOCALEDIR
をディレクトリ パスにセットします – セットしたディレクトリはドメインにlilypond-doc
を指定した.mo メッセージ カタログのツリーを保持する必要があります。texidoc
(Texinfo 出力専用です) 入力ファイル foo.ly に対して --header=texidoc オプションを指定して
lilypond
を呼び出した場合、入力ファイルの\header
にtexidoc
フィールドがあればファイル foo.texidoc が作成されます。texidoc
オプションはlilypond-book
にそのようなファイルをインクルードさせ、その内容を楽譜断片の直前 (ただし、quote
オプションによって生成されるexample
環境の外側) にドキュメントとして追加させます。ファイル foo.ly は以下を保持していて、
\header { texidoc = "This file demonstrates a single note." } { c'4 }
Texinfo ドキュメント test.texinfo に以下の記述があると仮定すると、
@lilypondfile[texidoc]{foo.ly}
以下のコマンドで期待した結果を得られます。
lilypond-book --pdf --process="lilypond \ --header=texidoc" test.texinfo
たいていの LilyPond テスト ドキュメント (配布ソースの input ディレクトリにあります) はこのような形の小さな .ly ファイルです。
ローカライズするために Texinfo ドキュメントが
@documentlanguage LANG
保持していて、foo.ly のヘッダがtexidocLANG
フィールドを保持している場合、--header=texidocLANG を付けてlilypond
を呼び出すと、foo.texidoc の代わりに foo.texidocLANG がインクルードされます。doctitle
(Texinfo 出力専用です) このオプションは
texidoc
オプションと同じような働きをします:\header
にdoctitle
フィールドを持つ入力ファイル foo.ly に対して --header=doctitle オプションを指定してlilypond
を呼び出した場合、foo.doctitle が生成されます。doctitle
オプションを使用した場合、foo.doctitle の内容 – 1 行のテキスト text である必要があります – は Texinfo ドキュメントに@lydoctitle text
として挿入されます。@lydoctitle
は Texinfo ドキュメントの中で定義されたマクロである必要があります。あとはローカライズされた言語に対するtexidoc
処理と同じ説明になります。nogettext
(Texinfo 出力専用です) 楽譜ソース引用の中にあるコメントと変数名を翻訳しません。
printfilename
\lilypondfile
で LilyPond 入力ファイルをインクルードした場合、楽譜断片の直前にインクルードしたファイルの名前を表示します。HTML 出力では、これはリンクになります。ファイルのベース名だけが表示されます – つまり、ファイル パスのディレクトリ部分は取り除かれます。
[ << lilypond-book を実行する ] | [Top][Contents][Index] | [ 外部プログラム >> ] |
[ < 楽譜断片オプション ] | [ Up : lilypond-book を実行する ] | [ ファイル拡張子 > ] |
3.4 lilypond-book
を呼び出す
lilypond-book
は出力形式に応じて以下の拡張子の 1 つを持つファイルを生成します: .tex, .texi, .html, あるいは
.xml。.tex, .texi, それに .xml のファイルは更なる処理を必要とします。
各出力形式に特有の説明
LaTeX
印刷や公開のために LaTeX ドキュメントを処理する方法は 2 つあります:
PDFLaTeX を用いて直接 PDF ファイルを得ることができ、dvips
のような PostScript への変換プログラムを用いて DVI 経由で PostScript
ファイルを得ることができます。1 つ目の方法は簡単で、お勧めです4。どのような方法を採るにせよ、Ghostscript パッケージに含まれる
ps2pdf
と pdf2ps
のようなツールを用いて PostScript
と PDF 間の変換は容易に行うことができます。
PDFLaTeX を用いて PDF ファイルを作り出すには、以下のようにします:
lilypond-book --pdf yourfile.lytex pdflatex yourfile.tex
LaTeX/dvips
/ps2pdf
経由で PDF ファイルを作り出すには、以下のようにします:
lilypond-book yourfile.lytex latex yourfile.tex dvips -Ppdf yourfile.dvi ps2pdf yourfile.ps
このプロセスで作成される .dvi ファイルは符頭を保持していません。それで通常です – 以下の手順に従うと、.ps ファイルや .pdf ファイルには符頭が含まれます。
dvips
を実行するとフォントに関する警告が発せられます:
それらは無害で無視できます。latex
を 2 列モードで実行するのであれば、忘れずに
dvips
のオプションに -t landscape を付け加えてください。
以下のような環境:
\begin{lilypond} … \end{lilypond}
は LaTeX では解釈されません。代わりに、lilypond-book
がこれらの‘環境’を専用ファイルに抽出し、LilyPond を呼び出します。そして出力結果の画像を用いて \begin{lilypond}
…\end{lilypond}
マクロが‘画像のインクルード’コマンドに置き換えられた .tex ファイルを生成します。LaTeX はこの時に実行します (\linewidth
などの計算を行うために LaTeX はその前に‘空の’ドキュメントで実行されているのですが)。
既知の問題と警告
\pageBreak
コマンドは \begin{lilypond} …
\end{lilypond}
環境の中では機能しません。
多くの \paper
ブロック変数も \begin{lilypond} …
\end{lilypond}
環境の中では機能しません。ドキュメント前文の中で \betweenLilyPondSystem
を持つ
\newcommand
を使ってください。
\newcommand{\betweenLilyPondSystem}[1]{\vspace{36mm}\linebreak}
Texinfo
(任意の出力形式の) Texinfo ドキュメントを作り出すには、Texinfo の通常の手順を踏みます。つまり、作り出そうとしている出力形式に応じて texi2pdf
か
texi2dvi
のどちらかを呼び出します。
詳細は Texinfo のドキュメントを参照してください。
コマンド ライン オプション
lilypond-book
は以下のコマンド ライン オプションを受け付けます:
-f format
--format=format
処理するドキュメントのタイプを指定します:
html
,latex
,texi
(デフォルト), あるいはdocbook
です。このオプションが無い場合、lilypond-book
は形式を自動的に検出しようとします – ファイル拡張子 を参照してください。今のところ、texi
はtexi-html
と同じです。-F filter
--filter=filter
楽譜ソース断片を filter に通します。
lilypond-book
は --filter と --process を一度に実行することはしません。例を挙げます:lilypond-book --filter='convert-ly --from=2.0.0 -' my-book.tely
-h
--help
短いヘルプ メッセージを表示します。
-I dir
--include=dir
インクルード パスに dir を追加します。
lilypond-book
はインクルード パスの中でコンパイル済みの楽譜断片を見つけると、それらを出力ディレクトリに書き出しません。そのため、lilypond-book
を呼び出してから更にtexi2any
やlatex
等のコマンドを同じ -I dir オプションを付けて呼び出す必要がある場合があります。-l loglevel
--loglevel=loglevel
出力の饒舌さを loglevel にセットします。取り得る値は
NONE
,ERROR
,WARN
,PROGRESS
(デフォルト), それにDEBUG
です。このオプションを使わなかった場合、環境変数LILYPOND_BOOK_LOGLEVEL
がセットされ、その値が loglevel として使われます。-o dir
--output=dir
生成されるファイルをディレクトリ dir に保存します。
lilypond-book
を実行すると LilyPond が処理するための多くの小さなファイルが生成されます。そのようなゴミがソース ディレクトリに混入することを防ぐには、--output コマンド ライン オプションを使用して出力ディレクトリを変更して、latex
やtexi2any
を実行する前にそのディレクトリに移動します。lilypond-book --output=out yourfile.lytex cd out …
--skip-lily-check
lilypond 出力が見つからなくても処理を終了しません。画像を持たない LilyPond Info ドキュメントを作成するために使います。
--skip-png-check
EPS ファイルを作成するための PNG 画像が見つからなくても処理を終了しません。画像を持たない LilyPond Info ドキュメントを作成するために使います。
--lily-output-dir=dir
lily-XXX ファイルをディレクトリ dir に書き出し、--output ディレクトリにリンクさせます。このオプションは別々のディレクトリの中にあり、多くの楽譜断片を共有するドキュメントをビルドする時間を節約するために使います。
--lily-loglevel=loglevel
呼び出された
lilypond
の出力の饒舌さを loglevel にセットします。取り得る値はNONE
,ERROR
,WARN
,BASIC
,PROGRESS
,INFO
(デフォルト), それにDEBUG
です。このオプションを使わなかった場合、環境変数LILYPOND_LOGLEVEL
がセットされ、その値が loglevel として使われます。--info-images-dir=dir
Texinfo 出力をフォーマットして、Info が dir の中にある楽譜画像を探すようにします。
--latex-program=prog
latex
の代わりに実行可能なprog
を実行します。これは、例えばドキュメントをxelatex
で処理する場合に有用です。--left-padding=amount
EPS ボックスのパディングを指定します。amount の単位はミリメートルで、デフォルト値は 3.0 です。このオプションは楽譜が右マージンに食い込む場合に使います。
The width of a tightly clipped system can vary, due to notation elements that stick into the left margin, such as bar numbers and instrument names. This option will shorten each line and move each line to the right by the same amount.
-P command
--process=command
LilyPond コード断片を command を用いて処理します。デフォルトのコマンドは
lilypond
です。lilypond-book
は --filter と --process を一度に実行することはしません。--pdf
PDFLaTeX で PDF ファイルを作成します。
--redirect-lilypond-output
デフォルトでは、出力はターミナルに表示されます。このオプションは全ての出力をソース ファイルと同じディレクトリにあるログ ファイルにリダイレクトします。
--use-source-file-names
楽譜断片出力ファイルにソース ファイルと同じベース名を付けます。このオプションは
lilypondfile
でインクルードされた楽譜断片に対してのみ、更に --output-dir オプションと --lily-output-dir オプションで指定されたディレクトリが異なる場合にのみ機能します。-V
--verbose
出力を饒舌にします。これは
--loglevel=DEBUG
と等価です。-v
--version
バージョン情報を表示します。
既知の問題と警告
Texinfo コマンド @pagesizes
は解釈されません。同様に、ドキュメント前文以降にあるマージンと行幅を変更する LaTeX
コマンドも無視されます。
LilyPond ブロックの最初の \score
だけが処理されます。
[ << lilypond-book を実行する ] | [Top][Contents][Index] | [ 外部プログラム >> ] |
[ < lilypond-book を呼び出す ] | [ Up : lilypond-book を実行する ] | [ lilypond-book テンプレート > ] |
3.5 ファイル拡張子
入力ファイルに対して任意のファイル拡張子を使うことができます。しかしながら、ある形式のファイルに対して推奨する拡張子を使わなかった場合、手動で出力形式を指定する必要があるかもしれません
– 詳細は lilypond-book
を呼び出す を参照してください。推奨する拡張子を使えば、lilypond-book
はその拡張子に基づいて自動的に出力形式を選択します。
拡張子 出力形式 .html HTML .htmly HTML .itely Texinfo .latex LaTeX .lytex LaTeX .lyxml DocBook .tely Texinfo .tex LaTeX .texi Texinfo .texinfo Texinfo .xml HTML
入力ファイルの拡張子を lilypond-book
が出力ファイルに付ける拡張子と同じで、入力ファイルが lilypond-book
の作業ディレクトリに置かれている場合、--output オプションを使って
lilypond-book
を実行する必要があります。そうしないと、“Output would overwrite input file” のようなエラー
メッセージが表示されて、終了します。
[ << lilypond-book を実行する ] | [Top][Contents][Index] | [ 外部プログラム >> ] |
[ < ファイル拡張子 ] | [ Up : lilypond-book を実行する ] | [ 目次を共有する > ] |
3.6 lilypond-book テンプレート
以下に示すテンプレートは lilypond-book
で使います。lilypond-book
に馴染みが無いのであれば、lilypond-book
を実行する を読んで下さい。
LaTeX
LilyPond 断片を LaTeX ドキュメントに組み込むことができます。
\documentclass[]{article} \begin{document} 通常の LaTeX テキスト。 \begin{lilypond} \relative { a'4 b c d } \end{lilypond} 次の LaTeX テキスト。オプションは角括弧の中に入れます。 \begin{lilypond}[fragment,relative=2,quote,staffsize=26,verbatim] d4 c b a \end{lilypond} \end{document}
Texinfo
LilyPond 断片を Texinfo に組み込むことができます。実際、このマニュアル全体が Texinfo で記述されています。
\input texinfo @node Top @top Texinfo テキスト @lilypond \relative { a4 b c d } @end lilypond 次の Texinfo テキスト。オプションは角括弧の中に入れます。 @lilypond[verbatim,fragment,ragged-right] d4 c b a @end lilypond @bye
html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML> <body> <p> 以下のように、lilypond-book 用のドキュメントには自由に楽譜と テキストを組み合わせることができます。 <lilypond> \relative { a'4 b c d } </lilypond> </p> <p> 次の lilypond コードにはオプションをつけます <lilypond fragment quote staffsize=26 verbatim> a4 b c d </lilypond> </p> </body> </html>
xelatex
\documentclass{article} \usepackage{ifxetex} \ifxetex %xetex specific stuff \usepackage{xunicode,fontspec,xltxtra} \setmainfont[Numbers=OldStyle]{Times New Roman} \setsansfont{Arial} \else %This can be empty if you are not going to use pdftex \usepackage[T1]{fontenc} \usepackage[utf8]{inputenc} \usepackage{mathptmx}%Times \usepackage{helvet}%Helvetica \fi %Here you can insert all packages that pdftex also understands \usepackage[ngerman,finnish,english]{babel} \usepackage{graphicx} \begin{document} \title{A short document with LilyPond and xelatex} \maketitle Normal \textbf{font} commands inside the \emph{text} work, because they \textsf{are supported by \LaTeX{} and XeteX.} If you want to use specific commands like \verb+\XeTeX+, you should include them again in a \verb+\ifxetex+ environment. You can use this to print the \ifxetex \XeTeX{} command \else XeTeX command \fi which is not known to normal \LaTeX . In normal text you can easily use LilyPond commands, like this: \begin{lilypond} {a2 b c'8 c' c' c'} \end{lilypond} \noindent and so on. The fonts of snippets set with LilyPond will have to be set from inside of the snippet. For this you should read the AU on how to use lilypond-book. \selectlanguage{ngerman} Auch Umlaute funktionieren ohne die \LaTeX -Befehle, wie auch alle anderen seltsamen Zeichen: __ ______, wenn sie von der Schriftart unterst__tzt werden. \end{document}
[ << lilypond-book を実行する ] | [Top][Contents][Index] | [ 外部プログラム >> ] |
[ < lilypond-book テンプレート ] | [ Up : lilypond-book を実行する ] | [ テキストと楽譜を組み合わせる他の方法 > ] |
3.7 目次を共有する
この機能はすでに OrchestralLily パッケージで用意されています:
より自由度の高いテキスト処理をするために、lilypond から目次をエクスポートして、LaTeX に読み込ませる方法を好むユーザもいるかもしれません。
LilyPond から目次をエクスポートする
以下のコードは、複数の楽章を 1 つのファイルに出力するものと仮定しています。
#(define (oly:create-toc-file layout pages) (let* ((label-table (ly:output-def-lookup layout 'label-page-table))) (if (not (null? label-table)) (let* ((format-line (lambda (toc-item) (let* ((label (car toc-item)) (text (caddr toc-item)) (label-page (and (list? label-table) (assoc label label-table))) (page (and label-page (cdr label-page)))) (format #f "~a, section, 1, {~a}, ~a" page text label)))) (formatted-toc-items (map format-line (toc-items))) (whole-string (string-join formatted-toc-items ",\n")) (output-name (ly:parser-output-name)) (outfilename (format #f "~a.toc" output-name)) (outfile (open-output-file outfilename))) (if (output-port? outfile) (display whole-string outfile) (ly:warning (G_ "Unable to open output file ~a for the TOC information") outfilename)) (close-output-port outfile))))) \paper { #(define (page-post-process layout pages) (oly:create-toc-file layout pages)) }
LaTeX に目次をインポートする
LaTeX ファイルのヘッダ中に以下を記述します:
\usepackage{pdfpages} \includescore{nameofthescore}
ここで、\includescore
は以下のように定義されています:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % \includescore{PossibleExtension} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Read in the TOC entries for a PDF file from the corresponding .toc file. % This requires some heave latex tweaking, since reading in things from a file % and inserting it into the arguments of a macro is not (easily) possible % Solution by Patrick Fimml on #latex on April 18, 2009: % \readfile{filename}{\variable} % reads in the contents of the file into \variable (undefined if file % doesn't exist) \newread\readfile@f \def\readfile@line#1{% {\catcode`\^^M=10\global\read\readfile@f to \readfile@tmp}% \edef\do{\noexpand\g@addto@macro{\noexpand#1}{\readfile@tmp}}\do% \ifeof\readfile@f\else% \readfile@line{#1}% \fi% } \def\readfile#1#2{% \openin\readfile@f=#1 % \ifeof\readfile@f% \typeout{No TOC file #1 available!}% \else% \gdef#2{}% \readfile@line{#2}% \fi \closein\readfile@f% }% \newcommand{\includescore}[1]{ \def\oly@fname{\oly@basename\@ifmtarg{#1}{}{_#1}} \let\oly@addtotoc\undefined \readfile{\oly@xxxxxxxxx}{\oly@addtotoc} \ifx\oly@addtotoc\undefined \includepdf[pages=-]{\oly@fname} \else \edef\includeit{\noexpand\includepdf[pages=-,addtotoc={\oly@addtotoc}] {\oly@fname}}\includeit \fi }
[ << lilypond-book を実行する ] | [Top][Contents][Index] | [ 外部プログラム >> ] |
[ < 目次を共有する ] | [ Up : lilypond-book を実行する ] | [ 外部プログラム > ] |
3.8 テキストと楽譜を組み合わせる他の方法
lilypond-book
を使わずにテキストと楽譜を組み合わせる方法を
LilyPond 出力を他のプログラムで使用する で説明しています。
[ << lilypond-book を実行する ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < テキストと楽譜を組み合わせる他の方法 ] | [ Up : Top ] | [ ポイント&クリック > ] |
4 外部プログラム
LilyPond は様々な方法で他のプログラムと連携することができます。
4.1 ポイント&クリック | ||
4.2 テキスト エディタ サポート | ||
4.3 他のフォーマットから変換する | ||
4.4 LilyPond 出力を他のプログラムで使用する | ||
4.5 独立した include |
[ << 外部プログラム ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < 外部プログラム ] | [ Up : 外部プログラム ] | [ システムを設定する > ] |
4.1 ポイント&クリック
ポイント&クリックは PDF ビューアの中で表記をクリックすることで入力の中の表記を見つけ出すことを可能にします。これは楽譜の中でエラーを引き起こす入力を見つけ出すことをより容易にします。
4.1.1 システムを設定する | ||
ポイント&クリックを有効にする | ||
選択的なポイント&クリック |
[ << 外部プログラム ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < ポイント&クリック ] | [ Up : ポイント&クリック ] | [ Xpdf を使用する > ] |
4.1.1 システムを設定する
この機能がアクティブな場合、LilyPond は PDF ファイルや SVG ファイルにハイパーリンクを付け加えます。これらのハイパーリンクは ‘URI ヘルパー’や Web ブラウザに送られ、テキスト エディタを開きカーソルを適切な位置に置きます。
この一連の動作を有効にするには、PDF ビューアが LilyPond で提供される lilypond-invoke-editor スクリプトを使ってハイパーリンクを追うように設定変更する必要があります。
プログラム lilypond-invoke-editor は小さな支援プログラムです。これは特別な textedit
URI に対してエディタを呼び出し、それ以外に対しては Web ブラウザを呼び出します。このプログラムは環境変数 EDITOR
と LYEDITOR
を調べて、ユーザの使用しているエディタを呼び出します。LYEDITOR
は EDITOR
よりも優先されるため、前者を使用することを推奨します。特に、ターミナル上で常用しているエディタとは別に、LilyPond のポイント アンド クリックのためのエディタを指定したい場合には、前者を使用してください。
エディタによって、行位置と列位置を指定してファイルを開くための引数の記法は異なります。ユーザの便宜のために、LilyPond にはいくつかのエディタに対するコマンドが予め登録されており、それは scm/editor.scm にリストアップされています。そのため、単にエディタのバイナリ名を変数に登録すれば動作します。例えば:
export LYEDITOR=atom
は以下を呼び出します:
atom %(file)s:%(line)s:%(column)s
%(file)s
, %(line)s
, %(column)s
はそれぞれファイル名、行、列で置き換えられます。
scm/editor.scm にリストアップされていないエディタを使用するには、LYEDITOR
に特定の記法でコマンド全体を登録します。以下は Visual Studio Code を使用する場合の例です:
export LYEDITOR="code --goto %(file)s:%(line)s:%(column)s"
Note: Emacs を使用している場合、追加の設定が必要となります。~/.emacs ファイルに (server-start)
という行を追加する必要があります。そうしなければ、PDF 内のオブジェクトをクリックする度に新しい Emacs ウィンドウが開いてしまいます。
Xpdf を使用する | ||
GNOME 2 を使用する | ||
GNOME 3 を使用する | ||
Evince のための追加の設定 |
[ << 外部プログラム ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < システムを設定する ] | [ Up : システムを設定する ] | [ GNOME 2 を使用する > ] |
Xpdf を使用する
UNIX で Xpdf を使用するには、xpdfrc に以下の記述が存在している必要があります。UNIX では、このファイルは /etc/xpdfrc あるいは $HOME/.xpdfrc として存在します。
urlCommand "lilypond-invoke-editor %s"
Ubuntu を使用している場合、システムにインストールされている Xpdf は全ての PDF ファイルでクラッシュを引き起こすかもしれません: この状態は数年間続いており、ライブラリの不一致が原因です。代わりに、Debian から現在のバージョンの ‘xpdf’ と対応する ‘libpoppler’ パッケージをインストールすると良いでしょう。これで動作が確認できたら、Ubuntu がクラッシュするパッケージの‘アップデート’で上書きしないように、
sudo apt-mark hold xpdf
を実行すると良いかもしれません。
[ << 外部プログラム ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < Xpdf を使用する ] | [ Up : システムを設定する ] | [ GNOME 3 を使用する > ] |
GNOME 2 を使用する
(PDF ビューアが統合されている) GNOME 2 を使用するには、‘textedit:’ URI をシステムに登録するために、以下のコマンドを実行します:
gconftool-2 -t string -s /desktop/gnome/url-handlers/textedit/command "lilypond-invoke-editor %s" gconftool-2 -s /desktop/gnome/url-handlers/textedit/needs_terminal false -t bool gconftool-2 -t bool -s /desktop/gnome/url-handlers/textedit/enabled true
そうしたら、
gnome-open textedit:///etc/issue:1:0:0
とすることで、ファイルを開くために lilypond-invoke-editor が実行されるはずです。
[ << 外部プログラム ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < GNOME 2 を使用する ] | [ Up : システムを設定する ] | [ Evince のための追加の設定 > ] |
GNOME 3 を使用する
GNOME 3 では、URI は ‘gconf’ ではなく ‘gvfs’ レイヤによって処理されます。 /tmp などのローカル ディレクトリに、lilypond-invoke-editor.desktop という名前で、以下の内容を持つファイルを作成してください:
[Desktop Entry] Version=1.0 Name=lilypond-invoke-editor GenericName=Textedit URI handler Comment=URI handler for textedit: Exec=lilypond-invoke-editor %u Terminal=false Type=Application MimeType=x-scheme-handler/textedit; Categories=Editor NoDisplay=true
そして以下のコマンドを実行してください:
xdg-desktop-menu install ./lilypond-invoke-editor.desktop xdg-mime default lilypond-invoke-editor.desktop x-scheme-handler/textedit
そうしたら、
gnome-open textedit:///etc/issue:1:0:0
とすることで、ファイルを開くために lilypond-invoke-editor が実行されるはずです。
[ << 外部プログラム ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < GNOME 3 を使用する ] | [ Up : システムを設定する ] | [ ポイント&クリックを有効にする > ] |
Evince のための追加の設定
gnome-open
は動作するが、Evince が権限が無いという理由でポイント&クリックを拒否する場合、Evince が実行できるアクションを規定する
Apparmor プロファイルを変更する必要があるかもしれません。
Ubuntu を使用している場合、/etc/apparmor.d/local/usr.bin.evince を編集し、以下の行を追加します:
# For Textedit links /usr/local/bin/lilypond-invoke-editor Cx -> sanitized_helper,
これらを追加したら、
sudo apparmor_parser -r -T -W /etc/apparmor.d/usr.bin.evince
を実行することで、Evince がポイント&クリックのリンクを開くことができるようになるはずです。他のビューアでも同じような設定が有効であるかもしれません。
[ << 外部プログラム ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < Evince のための追加の設定 ] | [ Up : ポイント&クリック ] | [ 選択的なポイント&クリック > ] |
ポイント&クリックを有効にする
ポイント&クリックの機能は PDF あるいは SVG ファイルを生成する時にデフォルトで有効化されています。
ポイント&クリックのリンクは出力ファイルを肥大化させます。これらのファイル (と PS ファイル) のサイズを小さくするには、.ly ファイルの中に以下を記述してポイント&クリックを OFF にします:
\pointAndClickOff
以下を用いて、ポイント&クリックを明示的に ON にすることができます:
\pointAndClickOn
.ly ファイルの中でポイント&クリックを OFF にする代わりにコマンド ライン オプションで OFF にすることができます:
lilypond -dno-point-and-click file.ly
Note: 配布する LilyPond ファイルでは常にポイント&クリックを OFF にして、PDF ファイルにあなたのコンピュータの Path 情報が含まれないようにすべきです。配布する .pdf ファイルに Path 情報が含まれているとセキュリティ リスクとなります。
[ << 外部プログラム ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < ポイント&クリックを有効にする ] | [ Up : ポイント&クリック ] | [ テキスト エディタ サポート > ] |
選択的なポイント&クリック
インタラクティブなアプリケーションでは、ある特定のポイント&クリック要素だけを含むことが望ましい場合もあります。例えば、誰かがある特定の音符から演奏を開始できるアプリケーションを作りたいと思った場合、音符をクリックした場合にその音符の上にある臨時記号やスラーのポイント&クリックが開いてしまったのでは不便です。
どのイベントをポイント&クリックに含めるか指定することで、これを制御できます:
- .ly ファイルにハード コードする:
\pointAndClickTypes #'note-event \relative { c'2\f( f) }
あるいは
#(ly:set-option 'point-and-click 'note-event) \relative { c'2\f( f) }
- コマンド ラインで指定する:
lilypond -dpoint-and-click=note-event example.ly
複数のイベントを含めることができます:
- .ly ファイルにハード コードする:
\pointAndClickTypes #'(note-event dynamic-event) \relative { c'2\f( f) }
あるいは
#(ly:set-option 'point-and-click '(note-event dynamic-event)) \relative { c'2\f( f) }
- コマンド ラインで指定する:
lilypond \ -e"(ly:set-option 'point-and-click '(note-event dynamic-event))" \ example.ly
[ << 外部プログラム ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < 選択的なポイント&クリック ] | [ Up : 外部プログラム ] | [ Emacs モード > ] |
4.2 テキスト エディタ サポート
いくつかのテキスト エディタの LilyPond サポート機能があります。
Emacs モード | ||
Vim モード | ||
その他のエディタ |
[ << 外部プログラム ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < テキスト エディタ サポート ] | [ Up : テキスト エディタ サポート ] | [ Vim モード > ] |
Emacs モード
Emacs は lilypond-mode を持ちます。これはキーワード自動補完、インデント挿入、LilyPond 特有の括弧一致、構文カラーリング、コンパイルへのショートカット、それに Info を用いての LilyPond マニュアル参照といった機能を持ちます。lilypond-mode があなたのプラットフォームにインストールされていないのであれば、以下を参照してください。
楽譜を記述して、LilyPond を実行するための Emacs モードは
elisp ディレクトリの中にあるソース アーカイブに保持されています。make install
を実行して、これを elispdir にインストールします。ファイル lilypond-init.el を load-path/sites-start.d/ に配置するか、~/.emacs または ~/.emacs.el に追記する必要があります。
~/.emacs に以下の行を追記 (あるいは修正) して、ソース パス (例えば ~/site-lisp/) を load-path に追加した方が良いかもしれません。
(setq load-path (append (list (expand-file-name "~/site-lisp")) load-path))
[ << 外部プログラム ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < Emacs モード ] | [ Up : テキスト エディタ サポート ] | [ その他のエディタ > ] |
Vim モード
Vim のために LilyPond 用のファイルタイプ プラグイン、インデント モード、それに構文ハイライト モードが用意されています。これらの機能をすべて有効にするには、$HOME/.vimrc が以下の 3 行を順序に従って保持するよう追記 (あるいは修正) します:
filetype off set runtimepath+=/usr/local/share/lilypond/current/vim/ filetype on syntax on
LilyPond が /usr/local にインストールされていない場合はパスを適切に変更してください。このトピックは その他の情報源 で議論されています。
[ << 外部プログラム ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < Vim モード ] | [ Up : テキスト エディタ サポート ] | [ 他のフォーマットから変換する > ] |
その他のエディタ
他にも LilyPond をサポートするエディタ (テキスト ベースとグラフィカル ベースの両方) がありますが、それらの特殊な設定ファイルは LilyPond では配布されません。更なる情報はそれらのエディタのドキュメントを参照してください。LilyPond をサポートするエディタは より簡単な編集手段 でリストアップされています。
[ << 外部プログラム ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < その他のエディタ ] | [ Up : 外部プログラム ] | [ midi2ly を呼び出す > ] |
4.3 他のフォーマットから変換する
楽譜の記述を他のフォーマットからインポートするもできます。この章では、配布プログラムに含まれるインポート ツールについて説明します。 LilyPond 入力を作り出すツールは他にもあります。例えば GUI シーケンスと XML コンバータです。詳細は website を参照してください。
上で述べたツールは lilypond
とは別のプログラムであり、コマンド ラインで実行します。詳細は コマンド ラインの使用方法 を参照してください。あなたが MacOS 10.3 や 10.4 を使っていて、これらのスクリプト (例えば convert-ly
) を実行する際に問題が発生した場合は、MacOS X を参照してください。
既知の問題と警告
残念なことに我々にはこれらのプログラムを維持していくだけの余力はありません。“これからの課題” になっていると考えてください。パッチは適用されていますが、バグ レポートはほとんど解決されていません。
4.3.1 midi2ly を呼び出す | MIDI をインポートする | |
4.3.2 musicxml2ly を呼び出す | MusicXML をインポートする | |
4.3.3 abc2ly を呼び出す | ABC をインポートする | |
4.3.4 etf2ly を呼び出す | Finale をインポートする | |
4.3.5 その他のフォーマット |
[ << 外部プログラム ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < 他のフォーマットから変換する ] | [ Up : 他のフォーマットから変換する ] | [ musicxml2ly を呼び出す > ] |
4.3.1 midi2ly
を呼び出す
midi2ly
は Type 1 MIDI ファイルを
LilyPond ソース ファイルに変換します。
MIDI (Music Instrument Digital Interface) は電子楽器の標準です: これはケーブル、シリアル プロトコル、それにファイル フォーマットを指定します。MIDI ファイル フォーマットは音楽を他のプログラムにエクスポートするためのデファクトスタンダードなフォーマットです。そのため、MIDI ファイルを扱う機能を持つことは、独自フォーマットを MIDI に変換できるプログラムのファイルをインポートする際に有用です。
midi2ly
はトラックを Staff コンテキストに変換し、チャネルを Voice コンテキストに変換します。ピッチには相対モードが使用され、演奏時間は必要がある場合にだけ記述されます。
デジタル キーボードを使って MIDI ファイルを録音し、それを .ly ファイルに変換することが可能です。しかしながら、人間の演奏者のリズムは LilyPond コンバータにかけられる
MIDI を作り出せるほど正確ではありません。量子化オプション (-s と -d オプション) を指定して
midi2ly
を呼び出すと、リズムの誤りを訂正しようとしますが、十分機能するとは言えません。このため、人間の演奏で生成された MIDI ファイルを midi2ly
で変換することはお勧めできません。
midi2ly
は以下のようにコマンド ラインから呼び出します:
midi2ly [option]… midi-file
‘コマンド ライン’ とは、OS のコマンド ラインを意味しているということに注意してください。このことについての更なる情報は 他のフォーマットから変換する を参照してください。
midi2ly
には以下のオプションがあります。
-a, --absolute-pitches
絶対ピッチで出力します。
-d, --duration-quant=DUR
音符の演奏時間を DUR で量子化します。
-e, --explicit-durations
すべての音符の演奏時間を出力します。
-h, --help
使用方法の要約を表示します。
-k, --key=acc[:minor]
デフォルトの調をセットします。acc > 0 はシャープの数をセットし、acc < 0 はフラットの数をセットします。短調は
:1
で指定します。-o, --output=file
file に出力します。
-s, --start-quant=DUR
音符の始まりを DUR で量子化します。
-t, --allow-tuplet=DUR*NUM/DEN
連符の演奏時間 DUR*NUM/DEN を許可します。
-v, --verbose
Verbose モード (ログ等が詳細) で実行します。
-V, --version
バージョン番号を表示します。
-w, --warranty
保証と著作権を表示します。
-x, --text-lyrics
すべてのテキストを歌詞として扱います。
既知の問題と警告
アルペジオでの音符のオーバラップは正しく変換されません。最初の音符は読み込まれますが、他の音符は無視されます。すべての音符を同時に開始させ、同じ演奏にして、フレーズ記号かペダル指示記号を追加してください。
[ << 外部プログラム ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < midi2ly を呼び出す ] | [ Up : 他のフォーマットから変換する ] | [ abc2ly を呼び出す > ] |
4.3.2 musicxml2ly
を呼び出す
MusicXML は音楽記譜を表すための XML の派生語です。
musicxml2ly
は ‘part-wise’
(時間軸優先ではなくパート優先の) MusicXML
から、音符、アーティキュレーション、楽譜構造、歌詞を抽出し、それらを .ly ファイルに記述します。このプログラムはコマンド ラインから以下のように呼び出します:
musicxml2ly [option]… file.xml
‘コマンド ライン’ とは、OS のコマンド ラインを意味しているということに注意してください。このことについての更なる情報は 他のフォーマットから変換する を参照してください。
ファイル名に file.xml ではなく - を指定すると、musicxml2ly
はすべての入力をコマンド ラインから受け付けます。
musicxml2ly
には以下のオプションがあります。
-a, --absolute
絶対ピッチで出力します。
--fb --fretboards
<frame>
イベントをマークアップではなく、分離された FretBoard ボイスに変換します。-h, --help
使用方法と使用可能なすべてのコマンドラインオプションの概要を表示します。
-l, --language=LANG
ピッチ名に LANG を使用します。例えば、ピッチ名にドイツ語を使用するには ’deutsch’ を指定します。
--loglevel=LOGLEVEL
出力の饒舌さを LOGLEVEL にセットします。取り得る値は
NONE
,ERROR
,WARN
,PROGRESS
(デフォルト), それにDEBUG
です。--lxml
XML 解析に lxml.etree Python パッケージを使用します。これはより少ないメモリと CPU 時間で実行されます。
-m, --midi
.ly ファイル中の MIDI ブロックを有効にします。
--nb, --no-beaming
連桁情報を変換せず、LilyPond の自動連桁機能を使用します。
--nd, --no-articulation-directions
アーティキュレーションや強弱等の指示 (
^
,_
あるいは-
) を変換しません。--nrp, --no-rest-positions
休符の垂直位置を変換しません。
--nsb, --no-system-breaks
システムの改行を無視します。
--npl, --no-page-layout
ページレイアウトと改行・改ページを変換しません(
--nsb
--npb
--npm
オプションのショートカットです)。--npb, --no-page-breaks
改ページを無視します。
--npm, --no-page-margins
ページの余白を無視します。
--nsd, --no-stem-directions
MusicXML の符幹の向きを無視し、代わりに lilypond の自動にします。
-o, --output=FILE
出力ファイル名を FILE とします。file に - を指定すると、出力は標準出力に表示されます。指定が無い場合、出力は xmlfile.ly となります。
-r, --relative
ピッチを相対モードに変換します。(デフォルト)
--transpose=TOPITCH
ピッチ
c
と TOPITCH 間の度数で移調します。--sm, --shift-meter=BEATS/BEATTYPE
与えられた拍子として音符の長さを変更して、速くしたり遅くしたりします(例:
4/4
または2/2
)。--tc, --tab-clef=TABCLEFNAME
タブ音部記号の 2 つのバージョン(
tab
とmoderntab
)を切り替えます。--sn --string-numbers=t[rue]/f[alse]
--string-numbers
false
で文字列番号ステンシルを無効にします。デフォルトはtrue
です。-v, --verbose
Verbose モード (ログ等が詳細) で実行します。
--version
バージョン情報を表示して終了します。
-z, --compressed
入力ファイルが ZIP で圧縮された MusicXML ファイルであることを示します。
[ << 外部プログラム ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < musicxml2ly を呼び出す ] | [ Up : 他のフォーマットから変換する ] | [ etf2ly を呼び出す > ] |
4.3.3 abc2ly
を呼び出す
Note: このプログラムは現在サポートされていません。LilyPond 将来のバージョンからは削除される可能性があります。
ABC は ASCII ベースの非常にシンプルなフォーマットです。このファイル形式について ABC のサイトで説明されています:
abc2ly
は ABC から LilyPond に変換を行います。以下のように呼び出します:
abc2ly [option]… abc-file
abc2ly
には以下のオプションがあります。
-b, --beams=None
ABC の連桁情報を保持します。
-h, --help
このオプション一覧を表示します。
-o, --output=file
出力ファイル名を file とします。
-s, --strict
be strict about success
--version
バージョン情報を表示します。
LilyPond コードを ABC ソース ファイルに付け加えるための簡単な機能があります。例えば以下のように記述した場合:
%%LY voices \set autoBeaming = ##f
キーワード ‘voices’ の後に続くテキストが LilyPond 出力ファイルのカレントのボイスに挿入されます。
同様に、
%%LY slyrics more words
これは、キーワード ‘slyrics’ の後に続くテキストを歌詞のカレント行に挿入します。
既知の問題と警告
ABC の標準はあくまでも ‘標準’ でしかありません。機能拡張 (例えば、多声音楽) のために、異なる書式があります。
1 つのファイルに複数の旋律を持つものは変換できません。
ABC は行の先頭で単語と音符との同期をとりますが、abc2ly
は同期をとりません。
abc2ly
は ABC の連桁を無視します。
[ << 外部プログラム ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < abc2ly を呼び出す ] | [ Up : 他のフォーマットから変換する ] | [ その他のフォーマット > ] |
4.3.4 etf2ly
を呼び出す
Note: このプログラムはサポートされていません。LilyPond 将来のバージョンからは削除される可能性があります。
ETF (Enigma Transport Format) は Coda Music Technology の Finale 製品に用いられるフォーマットです。etf2ly
は ETF ファイルの一部を
使用可能な LilyPond ファイルに変換します。
コマンド ラインからは以下のように呼び出します:
etf2ly [option]… etf-file
‘コマンド ライン’ とは、OS のコマンド ラインを意味しているということに注意してください。このことについての更なる情報は 他のフォーマットから変換する を参照してください。
etf2ly
には以下のオプションがあります。
-h, --help
このヘルプを表示します。
-o, --output=FILE
出力先のファイル名を FILE にします。
--version
バージョン情報を表示します。
既知の問題と警告
アーティキュレーションの一覧は未完成です。空の小節は etf2ly
を混乱させます。連続する装飾音符は正しく終了しません。
[ << 外部プログラム ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < etf2ly を呼び出す ] | [ Up : 他のフォーマットから変換する ] | [ LilyPond 出力を他のプログラムで使用する > ] |
4.3.5 その他のフォーマット
LilyPond 自体は他のフォーマットを一切サポートしませんが、外部ツールで LilyPond ファイルを生成することができます。それらのツールは より簡単な編集手段 でリストアップされています。
[ << 外部プログラム ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < その他のフォーマット ] | [ Up : 外部プログラム ] | [ LuaTeX > ] |
4.4 LilyPond 出力を他のプログラムで使用する
このセクションでは、lilypond-book
を用いた自動手法ではない、テキストと楽譜を統合する手法を示します。
4.4.1 LuaTeX | ||
4.4.2 OpenOffice と LibreOffice | ||
4.4.3 他のプログラム |
[ << 外部プログラム ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < LilyPond 出力を他のプログラムで使用する ] | [ Up : LilyPond 出力を他のプログラムで使用する ] | [ OpenOffice と LibreOffice > ] |
4.4.1 LuaTeX
lilypond-book
でも LilyPond 出力を組み込むことができますが、
LuaTeX を使用する場合、lyluatex
と呼ばれる代替プログラムがあります。
[ << 外部プログラム ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < LuaTeX ] | [ Up : LilyPond 出力を他のプログラムで使用する ] | [ 他のプログラム > ] |
4.4.2 OpenOffice と LibreOffice
OOoLilyPond を用いて LilyPond 出力を OpenOffice.org と LibreOffice に付け加えることができます。これは OpenOffice.org のドキュメント内で LilyPond のファイルを画像に変換する OpenOffice.org の拡張機能です。 OoLilyPond (OLy) は、LibreOffice および OpenOffice の最新バージョンで動作します。古いバージョンでも動作するはずです。OpenOffice 2.4 でも問題なくテストされています。
[ << 外部プログラム ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < OpenOffice と LibreOffice ] | [ Up : LilyPond 出力を他のプログラムで使用する ] | [ 独立した include > ] |
4.4.3 他のプログラム
PNG, EPS, PDF を扱うことができる他のプログラムでは、lilypond-book
ではなく、lilypond
を使用します。LilyPond 出力ファイルを 1 つずつ作成し挿入する必要があります。
他のソースからファイルを挿入する方法について、それぞれのプログラムのドキュメントを参照してください。
LilyPond 楽譜の周りの空白を減らすには、以下のオプションを使用します:
\paper{ indent=0\mm line-width=120\mm oddFooterMarkup=##f oddHeaderMarkup=##f bookTitleMarkup = ##f scoreTitleMarkup = ##f } … music …
EPS ファイルを生成するには:
lilypond -dbackend=eps -dno-gs-load-fonts -dinclude-eps-fonts myfile.ly
PNG ファイルを生成するには:
lilypond -dbackend=eps -dno-gs-load-fonts -dinclude-eps-fonts --png myfile.ly
透過 PNG ファイルを生成するには:
lilypond -dbackend=eps -dno-gs-load-fonts -dinclude-eps-fonts -dpixmap-format=pngalpha --png myfile.ly
大きなスコアから多くの断片を引用したい場合、クリップ機能を用いることができます。音楽の断片を抽出する を参照してください。
[ << 外部プログラム ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < 他のプログラム ] | [ Up : 外部プログラム ] | [ MIDI アーティキュレーション > ] |
4.5 独立した include
出力にある効果を生み出すために、LilyPond に \include
することのできるファイルを作っているユーザがいます。以下にあるものは LilyPond に付属しているものです。入力ファイルに取り組む も参照してください。
4.5.1 MIDI アーティキュレーション |
[ << 外部プログラム ] | [Top][Contents][Index] | [ LilyPond 入力ファイルの記述に対する提案 >> ] |
[ < 独立した include ] | [ Up : 独立した include ] | [ LilyPond 入力ファイルの記述に対する提案 > ] |
4.5.1 MIDI アーティキュレーション
Articulate プロジェクトは LilyPond の MIDI 出力を改善しようとするものです。これは (スラーの中に無い) 音符の長さを、アーティキュレーションに合わせて調整することによって実現されています。例えば、‘スタッカート’は音長を半分にし、‘テヌート’は音符いっぱいの音長にします。Enhancing MIDI output を参照してください。
[ << 外部プログラム ] | [Top][Contents][Index] | [ GNU Free Documentation License >> ] |
[ < MIDI アーティキュレーション ] | [ Up : Top ] | [ 一般的な提案 > ] |
5 LilyPond 入力ファイルの記述に対する提案
今やあなたはもっと大きな LilyPond 入力ファイル – チュートリアルにあるような小さな例ではなく、楽曲全体 – を書き始める準備が整っています。しかしながら、どのように書き進めていくべきなのでしょうか?
LilyPond があなたの入力ファイルを理解でき、望みの出力を作り出している限り、あなたの入力ファイルがどのようなものであるかは問題になりません。しかしながら、LilyPond 入力ファイルを書いているときに考慮すべきことが他にもいくつかあります。
- あなたがミスをしたとしたらどうでしょうか?LilyPond ファイルの構造はエラーを見つけ出すことをより容易に (あるいはより困難に) します。
- あなたがあなたの入力ファイルを誰か他の人と共有したいとしたらどうでしょうか?実際には、あなたが数年前のあなた自身の入力ファイルを変更したいとしたらどうでしょうか?一読して理解可能な LilyPond 入力ファイルがある一方で、あなたを 1 時間も悩ます入力ファイルもあるかもしれません。
- あなたがあなたの LilyPond ファイルを最近のバージョンの LilyPond のためにアップグレードしたいとしたらどうでしょうか?入力構文は LilyPond の改良に合わせてしばしば変更されます。たいていの変更は
convert-ly
で自動的に変換できますが、いくつかの変更は手動での援助を必要とするかもしれません。LilyPond 入力ファイルはより容易に (あるいはより困難に) 更新できるように構成することができます。
5.1 一般的な提案 | ||
5.2 既存の音楽を譜刻する | ||
5.3 大きなプロジェクト | ||
5.4 トラブルシュート | ||
5.5 Make と Makefile |
[ << LilyPond 入力ファイルの記述に対する提案 ] | [Top][Contents][Index] | [ GNU Free Documentation License >> ] |
[ < LilyPond 入力ファイルの記述に対する提案 ] | [ Up : LilyPond 入力ファイルの記述に対する提案 ] | [ 既存の音楽を譜刻する > ] |
5.1 一般的な提案
ここで、譜刻の際に起こる、最もよくある問題を回避 (あるいは修正) する手助けになりうる提案をいくつか挙げます:
- どんなに小さいファイルでも、すべての入力ファイルに必ず
\version
番号を含めるべきです。これは、LilyPond のどのバージョンでファイルが作られたかを覚えておかなくて良くなりますし、convert-ly
を使ってファイルを更新する の際に特に関わってきます (convert-ly は\version
が含まれている必要があります)。あるいは他のユーザに入力ファイルを送る際 (例えばメーリング リストで助けを得るとき) にも重要です。テンプレートはすべて\version
情報を保持しているということに注意してください。 - 入力ファイル 1 行につき、1 小節の音楽を書きます。 これは入力ファイルに関するあらゆる問題のデバッグを簡単にします。
- 小節と小節番号のチェックとオクターブ チェックを含めます。入力ファイルにこのような‘チェック’を含めておくことで、ミスを特定するのが早くなります。チェックをどのぐらいの頻度で追加するかは、その音楽の複雑さ次第です。簡単な音楽であれば、戦略上重要なポイントにいくつか追加するだけで十分でしょう。しかし、多くの声部や譜を持つようなもっと複雑な音楽であれば、おそらく各小節にチェックを入れたほうが良いでしょう。
- 入力ファイルにコメントをつけます。コメントとして音楽テーマへの参照 (‘ヴァイオリンの第 2 テーマ’, ‘第 4 変奏’) など) や、単純に小節番号を追加することは、入力ファイルの中の場所を特定するのを簡単にします。特に後で何かを変更しなければならない場合や、LilyPond 入力ファイルを他の人に渡す際には特に役立ちます。
- セクションの開始時に明示的に演奏時間を付け加えます。例えば、ただ
c d e f
と書く代わりにc4 d e f
と書くことで、後で音楽を再配置するのが簡単になります。 - 波括弧と並列表記にインデントを施します。問題はしばしば、どちらかの括弧が‘足りない’ことが原因です。波括弧の‘始まり’と‘終わり’
(あるいは
<<
と>>
) に明確なインデントを追加することで、このような問題を避けやすくなります。例えば以下の入力:\new Staff { \relative { r4 g'8 g c8 c4 d | e4 r8 | % Ossia section << { f8 c c | } \new Staff { f8 f c | } >> r4 | } }
は以下の入力より括弧の対応を追いかけやすいです:
\new Staff { \relative { r4 g'8 g c4 c8 d | e4 r8 % Ossia section << { f8 c c } \new Staff { f8 f c } >> r4 | } }
-
\layout
ブロックにオーバライドを追加することによって、音楽とスタイルを分割します:\score { …music… \layout { \override TabStaff.Stemstencil = ##f } }
このオーバライドは新しいコンテキストを生成しませんが、コンテキストが生成された際に適用されます。変数と関数を用いて入力の手間を省くやスタイル シートも参照してください。
[ << LilyPond 入力ファイルの記述に対する提案 ] | [Top][Contents][Index] | [ GNU Free Documentation License >> ] |
[ < 一般的な提案 ] | [ Up : LilyPond 入力ファイルの記述に対する提案 ] | [ 大きなプロジェクト > ] |
5.2 既存の音楽を譜刻する
既存の楽譜からの音楽を入力している (つまり、既存の楽譜の楽曲を譜刻している) のなら、
- 1 回につき 1 つのシステム
(訳者: システムとは譜の集まりのこと。例えば、ピアノ譜での 1 システムとは、右手譜 1 小節とそれに対応する左手譜 1 小節)
を入力し (しかし、それでもテキスト 1 行につき 1 小節だけにします)、それを終えたときに各システムをチェックします。処理をスピード アップさせるために
showLastLength
プロパティやshowFirstLength
プロパティを使うことになるかもしれません – Skipping corrected music を参照してください。 -
mBreak = { \break }
を定義して、写している楽譜が改行するたびに\mBreak
を入力ファイルに挿入します。これにより、LilyPond の音楽とオリジナルの音楽を比較することがずっと容易になります。入力した楽譜の校正が終わったときに、それらの改行すべてを削除するためにmBreak = { }
を定義することになるかもしれません。これにより、LilyPond は LilyPond が最適と思う場所に改行を入れることができるようになります。 - 移調楽器のパートは変数に入力します。移調楽器の音符は以下で囲むことを推奨します:
\transpose c natural-pitch {…}
(
natural-pitch
はその楽器のオープン ピッチです) これにより、変数の中の音楽は C で効率的に記述することができます。変数を使用していれば、必要なときに移調しなおすこともできます (例えば、楽譜をコンサート ピッチで譜刻したり、トロンボーン パートをト音記号からヘ音記号に変換したり、など)。音楽をすべて変数の中に首尾一貫したピッチで記述しておけば、移調のミスは起こりにくくなります。また、移調が C との間で行われるだけ – つまり、他に使用する調が楽器のナチュラル ピッチだけ: B-フラット トランペットなら bes、A-フラット クラリネットなら aes – であるとしても、音楽を変数に格納しておくべきです。
[ << LilyPond 入力ファイルの記述に対する提案 ] | [Top][Contents][Index] | [ GNU Free Documentation License >> ] |
[ < 既存の音楽を譜刻する ] | [ Up : LilyPond 入力ファイルの記述に対する提案 ] | [ トラブルシュート > ] |
5.3 大きなプロジェクト
大きなプロジェクトに取り組んでいるとき、LilyPond 入力ファイルの構造をすっきりさせておくことが不可欠です。
- 各ボイスに対して変数を使用して、定義の中の構造を最小限にします。
\score
セクションの構造が最も変更される可能性が高い箇所です。一方、violin
定義は LilyPond のバージョンが新しくなっても変更される可能性はまずありません。violin = \relative { g'4 c'8. e16 } … \score { \new GrandStaff { \new Staff { \violin } } }
- 調整を音楽定義から分離します。このことは前にも触れましたが、大きなプロジェクトでは絶対に不可欠なことです。
fthenp
の定義を変更する必要が生じた場合、変更は 1 回で済み、violin
の内部にはまったく手を触れる必要がありません。fthenp = _\markup{ \dynamic f \italic \small { 2nd } \hspace #0.1 \dynamic p } violin = \relative { g'4\fthenp c'8. e16 }
[ << LilyPond 入力ファイルの記述に対する提案 ] | [Top][Contents][Index] | [ GNU Free Documentation License >> ] |
[ < 大きなプロジェクト ] | [ Up : LilyPond 入力ファイルの記述に対する提案 ] | [ Make と Makefile > ] |
5.4 トラブルシュート
遅かれ早かれ、あなたは LilyPond がコンパイルできないファイルを書くことになります。LilyPond が返すメッセージはエラーを見つけ出す手助けになるかもしれませんが、多くの場合、問題の原因を探し出すために調査を行う必要があります。
この目的のための最も強力なツールは 1 行コメント (%
で記述します) とブロック コメント (%{…%}
で記述します) です。問題がどこにあるかわからない場合、入力ファイルの大きな一部分をコメント アウトすることから始めます。あるセクションをコメント アウトして、そのファイルを再びコンパイルしてみます。コンパイルが通ったのなら、問題は今コメント アウトした部分の中にあります。コンパイルが通らなかった場合は、コンパイルが通るようになるまでコメント アウトしたままにしておきます。
極端な場合、最終的に以下のようになるかもしれません:
\score { << % \melody % \harmony % \bass >> \layout{} }
(言い換えると、何の音楽も持たないファイルです)
こうなったとしても、あきらめないでください。少しだけコメントを外して – 例えば、バス パートを –
コンパイルが通るかどうか試してみます。コンパイルが通らなかった場合は、バスの音楽をすべてコメント アウトします
(しかし、\score
の中の \bass
はコメントを外したままにしておきます)。
bass = \relative { %{ c'4 c c c d d d d %} }
そして、問題を起こしている行を見つけ出すまで、bass
パートから少しずつコメントを外していきます。
もう 1 つの非常に有用なデバッグ テクニックは Tiny examples を構築することです。
[ << LilyPond 入力ファイルの記述に対する提案 ] | [Top][Contents][Index] | [ GNU Free Documentation License >> ] |
[ < トラブルシュート ] | [ Up : LilyPond 入力ファイルの記述に対する提案 ] | [ GNU Free Documentation License > ] |
5.5 Make と Makefile
LilyPond を実行できるほとんどすべてのプラットフォームが
make
というソフトウェアをサポートします。このソフトウェアは Makefile
という名前の特殊なファイルを読み込みます。ファイル Makefile
は、ファイルの依存関係と、あるファイルから別のファイルを作り出すためにオペレーティング システムに渡す必要があるコマンドを定義します。例えば、Makefile
は LilyPond を実行して
ballad.ly
から ballad.pdf
と ballad.midi
を作り出す方法を記述します。
自身の便利さのためかソース ファイルにアクセスしてくれる他の人のために、自身のプロジェクト用に Makefile
を作成することが良い場合があります。これが当てはまるのは、多くのインクルード ファイルと複数の出力オプション
(例えば、フル スコア、パート スコア、指揮譜、ピアノ譜など) を持つ
非常に大きなプロジェクト、あるいは、ビルドするために複雑なコマンドを必要とするプロジェクト
(lilypond-book
プロジェクトなど)
です。Makefile
の複雑さと自由度は、必要性と作者のスキルに応じて、さまざまです。プログラム GNU Make は
GNU/Linux ディストリビューションと MacOS X にインストールされていて、Windows でも利用可能です。
make
の使い方についてのすべての詳細は
GNU Make マニュアル を参照してください。これから示すのは make
でできることのほんの一例です。
Makefile
の中に規則を定義するためのコマンドは、プラットフォームによって異なります。例えば、さまざまな種類がある GNU/Linux と MacOS は bash
を使いますが、Windows は cmd
を使います。MacOS X では、コマンド ライン インタプリタを使用するためにシステムをコンフィグレーションする必要があるということに注意してください。ここで、Makefile
の例をいくつか
GNU/Linux/MacOS 用と Windows 用の両方のバージョンで示します。
最初の例は、4 楽章のオーケストラのためのもので、以下のようなディレクトリ構造を持ちます:
Symphony/ |-- MIDI/ |-- Makefile |-- Notes/ | |-- cello.ily | |-- figures.ily | |-- horn.ily | |-- oboe.ily | |-- trioString.ily | |-- viola.ily | |-- violinOne.ily | `-- violinTwo.ily |-- PDF/ |-- Parts/ | |-- symphony-cello.ly | |-- symphony-horn.ly | |-- symphony-oboes.ly | |-- symphony-viola.ly | |-- symphony-violinOne.ly | `-- symphony-violinTwo.ly |-- Scores/ | |-- symphony.ly | |-- symphonyI.ly | |-- symphonyII.ly | |-- symphonyIII.ly | `-- symphonyIV.ly `-- symphonyDefs.ily
Scores
ディレクトリと Parts
ディレクトリの中にある
.ly
ファイルは音符を
Notes
ディレクトリの中にある .ily
ファイルから取得します:
%%% top of file "symphony-cello.ly" \include ../symphonyDefs.ily \include ../Notes/cello.ily
この Makefile
はターゲットとして
score
(フル スコアの楽曲全体)、movements
(フル スコアの個々の楽章)、それに parts
(演奏者のための個々のパート) を持ちます。さらに、web や email で配布するのに適したソース ファイルの tarball
(訳者: 複数のファイルをコマンド tar
で 1 つのファイルにまとめたもの)
を作成するターゲット archive
もあります。ここでは GNU/Linux や MacOS X 用の Makefile
を示します。これをプロジェクトのトップ ディレクトリに
Makefile
という名前で保存する必要があります:
Note: ターゲットやパターン ルールが定義されたとき、そのあとの行はスペースではなく Tab で始まる必要があります。
# 出力ファイル名 piece = symphony # いくつプロセッサがあるかを決定します CPU_CORES=`cat /proc/cpuinfo | grep -m1 "cpu cores" | sed s/".*: "//` # lilypond を実行するコマンド LILY_CMD = lilypond -ddelete-intermediate-files \ -dno-point-and-click -djob-count=$(CPU_CORES) # この Makefile で使用される拡張子 .SUFFIXES: .ly .ily .pdf .midi # 入力ファイルと出力ファイルのサーチは VPATH 変数でリストアップされている # ディレクトリの中で行われます。それらのディレクトリはすべて (GNU make 変数 # `CURDIR' によって与えられる) カレント ディレクトリのサブディレクトリです。 VPATH = \ $(CURDIR)/Scores \ $(CURDIR)/PDF \ $(CURDIR)/Parts \ $(CURDIR)/Notes # LY 入力ファイルから PDF ファイルと MIDI ファイルを作成するための # パターン ルール。.pdf 出力ファイルは `PDF' サブディレクトリの中に # 配置され、.midi ファイルは `MIDI' サブディレクトリの中に配置されます。 %.pdf %.midi: %.ly $(LILY_CMD) $<; \ # this line begins with a tab if test -f "$*.pdf"; then \ mv "$*.pdf" PDF/; \ fi; \ if test -f "$*.midi"; then \ mv "$*.midi" MIDI/; \ fi notes = \ cello.ily \ horn.ily \ oboe.ily \ viola.ily \ violinOne.ily \ violinTwo.ily # 楽章の依存関係 $(piece)I.pdf: $(piece)I.ly $(notes) $(piece)II.pdf: $(piece)II.ly $(notes) $(piece)III.pdf: $(piece)III.ly $(notes) $(piece)IV.pdf: $(piece)IV.ly $(notes) # 総譜の依存関係 $(piece).pdf: $(piece).ly $(notes) # パート譜の依存関係 $(piece)-cello.pdf: $(piece)-cello.ly cello.ily $(piece)-horn.pdf: $(piece)-horn.ly horn.ily $(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily $(piece)-viola.pdf: $(piece)-viola.ly viola.ily $(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily $(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily # 4 つすべての楽章のフル スコアを 1 つのファイルとして生成するには # `make score' とタイプします。 .PHONY: score score: $(piece).pdf # すべてのパートを生成するには `make parts' とタイプします。 # 楽器 `foo' のためのパートを生成するには `make foo.pdf' とタイプします。 # 例: `make symphony-cello.pdf' .PHONY: parts parts: $(piece)-cello.pdf \ $(piece)-violinOne.pdf \ $(piece)-violinTwo.pdf \ $(piece)-viola.pdf \ $(piece)-oboes.pdf \ $(piece)-horn.pdf # 4 つの楽章を別個のファイルとして生成するには `make movements' とタイプします。 .PHONY: movements movements: $(piece)I.pdf \ $(piece)II.pdf \ $(piece)III.pdf \ $(piece)IV.pdf all: score parts movements archive: tar -cvvf stamitz.tar \ # this line begins with a tab --exclude=*pdf --exclude=*~ \ --exclude=*midi --exclude=*.tar \ ../Stamitz/*
Windows プラットフォームには特別な面倒さがあります。Windows 用の GNU Make をダウンロードしてインストールした後、システム環境変数に正しいパスを設定して、DOS シェルが Make プログラムを見つけられるようにする必要があります。これを行うには、"マイ コンピュータ" を右クリックして、プロパティ
を選択し、それから 詳細設定
を選択します。それから 環境変数
をクリックして、システム環境変数
パネルの中にある Path
をハイライトしてから
編集
をクリックして、GNU Make の実行ファイルへのパスを追加します。そのパスは以下のようになります
(訳者: GNU Make のインストールのされ方によって異なります):
C:\Program Files\GnuWin32\bin
Linux/MacOS X とは異なるシェル コマンドを扱い、いくつかのデフォルト システム ディレクトリの中に存在するファイル空間を扱うために、Makefile
自体を変更する必要があります。Windows は tar
コマンドを持たないため、archive
ターゲットは除去されます。また、Windows が持つ MIDI ファイルのデフォルト拡張子は異なります。
## WINDOWS VERSION ## piece = symphony LILY_CMD = lilypond -ddelete-intermediate-files \ -dno-point-and-click \ -djob-count=$(NUMBER_OF_PROCESSORS) #get the 8.3 name of CURDIR (workaround for spaces in PATH) workdir = $(shell for /f "tokens=*" %%b in ("$(CURDIR)") \ do @echo %%~sb) .SUFFIXES: .ly .ily .pdf .mid VPATH = \ $(workdir)/Scores \ $(workdir)/PDF \ $(workdir)/Parts \ $(workdir)/Notes %.pdf %.mid: %.ly $(LILY_CMD) $< # this line begins with a tab if exist "$*.pdf" move /Y "$*.pdf" PDF/ # begin with tab if exist "$*.mid" move /Y "$*.mid" MIDI/ # begin with tab notes = \ cello.ily \ figures.ily \ horn.ily \ oboe.ily \ trioString.ily \ viola.ily \ violinOne.ily \ violinTwo.ily $(piece)I.pdf: $(piece)I.ly $(notes) $(piece)II.pdf: $(piece)II.ly $(notes) $(piece)III.pdf: $(piece)III.ly $(notes) $(piece)IV.pdf: $(piece)IV.ly $(notes) $(piece).pdf: $(piece).ly $(notes) $(piece)-cello.pdf: $(piece)-cello.ly cello.ily $(piece)-horn.pdf: $(piece)-horn.ly horn.ily $(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily $(piece)-viola.pdf: $(piece)-viola.ly viola.ily $(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily $(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily .PHONY: score score: $(piece).pdf .PHONY: parts parts: $(piece)-cello.pdf \ $(piece)-violinOne.pdf \ $(piece)-violinTwo.pdf \ $(piece)-viola.pdf \ $(piece)-oboes.pdf \ $(piece)-horn.pdf .PHONY: movements movements: $(piece)I.pdf \ $(piece)II.pdf \ $(piece)III.pdf \ $(piece)IV.pdf all: score parts movements
次の Makefile
は、LaTeX で処理する lilypond-book
ドキュメント用です。このドキュメントは目次を持ちます。目次を作成するには、リンクを更新するために latex
コマンドを 2 回実行する必要があります。.pdf 出力ファイルは out
ディレクトリに保存され、HTML 出力ファイルは htmlout
ディレクトリに保存されます。
SHELL=/bin/sh FILE=myproject OUTDIR=out WEBDIR=htmlout VIEWER=acroread BROWSER=firefox LILYBOOK_PDF=lilypond-book --output=$(OUTDIR) --pdf $(FILE).lytex LILYBOOK_HTML=lilypond-book --output=$(WEBDIR) $(FILE).lytex PDF=cd $(OUTDIR) && pdflatex $(FILE) HTML=cd $(WEBDIR) && latex2html $(FILE) INDEX=cd $(OUTDIR) && makeindex $(FILE) PREVIEW=$(VIEWER) $(OUTDIR)/$(FILE).pdf & all: pdf web keep pdf: $(LILYBOOK_PDF) # begin with tab $(PDF) # begin with tab $(INDEX) # begin with tab $(PDF) # begin with tab $(PREVIEW) # begin with tab web: $(LILYBOOK_HTML) # begin with tab $(HTML) # begin with tab cp -R $(WEBDIR)/$(FILE)/ ./ # begin with tab $(BROWSER) $(FILE)/$(FILE).html & # begin with tab keep: pdf cp $(OUTDIR)/$(FILE).pdf $(FILE).pdf # begin with tab clean: rm -rf $(OUTDIR) # begin with tab web-clean: rm -rf $(WEBDIR) # begin with tab archive: tar -cvvf myproject.tar \ # begin this line with tab --exclude=out/* \ --exclude=htmlout/* \ --exclude=myproject/* \ --exclude=*midi \ --exclude=*pdf \ --exclude=*~ \ ../MyProject/*
TODO: make this thing work on Windows
この Makefile
は Windows では機能しません。Windows ユーザの代替手段として、ビルド コマンドを保持する簡単なバッチ ファイルを作成する方法があります。これは Makefile
のように依存関係を保持できませんが、少なくともビルド処理を単一のコマンドに縮小します。以下のコードを
build.bat
あるいは build.cmd
として保存してください。このバッチ ファイルは DOS プロンプトから実行することができ、単にそのアイコンをダブル クリックすることでも実行することができます。
lilypond-book --output=out --pdf myproject.lytex cd out pdflatex myproject makeindex myproject pdflatex myproject cd .. copy out\myproject.pdf MyProject.pdf
参照
アプリケーションの使用方法:
コマンド ラインの使用方法,
lilypond-book
を実行する
[ << LilyPond 入力ファイルの記述に対する提案 ] | [Top][Contents][Index] | [ LilyPond インデックス >> ] |
[ < Make と Makefile ] | [ Up : Top ] | [ LilyPond インデックス > ] |
Appendix A GNU Free Documentation License
Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. https://fsf.org/ Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
- PREAMBLE
The purpose of this License is to make a manual, textbook, or other functional and useful document free in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.
This License is a kind of “copyleft”, which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.
We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.
- APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The “Document”, below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as “you”. You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.
A “Modified Version” of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.
A “Secondary Section” is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document’s overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.
The “Invariant Sections” are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.
The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.
A “Transparent” copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not “Transparent” is called “Opaque”.
Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.
The “Title Page” means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, “Title Page” means the text near the most prominent appearance of the work’s title, preceding the beginning of the body of the text.
The “publisher” means any person or entity that distributes copies of the Document to the public.
A section “Entitled XYZ” means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as “Acknowledgements”, “Dedications”, “Endorsements”, or “History”.) To “Preserve the Title” of such a section when you modify the Document means that it remains a section “Entitled XYZ” according to this definition.
The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.
- VERBATIM COPYING
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you may publicly display copies.
- COPYING IN QUANTITY
If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document’s license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.
- MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:
- Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.
- List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.
- State on the Title page the name of the publisher of the Modified Version, as the publisher.
- Preserve all the copyright notices of the Document.
- Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
- Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.
- Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document’s license notice.
- Include an unaltered copy of this License.
- Preserve the section Entitled “History”, Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled “History” in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.
- Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the “History” section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.
- For any section Entitled “Acknowledgements” or “Dedications”, Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.
- Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.
- Delete any section Entitled “Endorsements”. Such a section may not be included in the Modified Version.
- Do not retitle any existing section to be Entitled “Endorsements” or to conflict in title with any Invariant Section.
- Preserve any Warranty Disclaimers.
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version’s license notice. These titles must be distinct from any other section titles.
You may add a section Entitled “Endorsements”, provided it contains nothing but endorsements of your Modified Version by various parties—for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.
- COMBINING DOCUMENTS
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections Entitled “History” in the various original documents, forming one section Entitled “History”; likewise combine any sections Entitled “Acknowledgements”, and any sections Entitled “Dedications”. You must delete all sections Entitled “Endorsements.”
- COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
- AGGREGATION WITH INDEPENDENT WORKS
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an “aggregate” if the copyright resulting from the compilation is not used to limit the legal rights of the compilation’s users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document’s Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.
- TRANSLATION
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.
If a section in the Document is Entitled “Acknowledgements”, “Dedications”, or “History”, the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.
- TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, or distribute it is void, and will automatically terminate your rights under this License.
However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.
Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.
Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, receipt of a copy of some or all of the same material does not give you any rights to use it.
- FUTURE REVISIONS OF THIS LICENSE
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See https://www.gnu.org/licenses/.
Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License “or any later version” applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. If the Document specifies that a proxy can decide which future versions of this License can be used, that proxy’s public statement of acceptance of a version permanently authorizes you to choose that version for the Document.
- RELICENSING
“Massive Multiauthor Collaboration Site” (or “MMC Site”) means any World Wide Web server that publishes copyrightable works and also provides prominent facilities for anybody to edit those works. A public wiki that anybody can edit is an example of such a server. A “Massive Multiauthor Collaboration” (or “MMC”) contained in the site means any set of copyrightable works thus published on the MMC site.
“CC-BY-SA” means the Creative Commons Attribution-Share Alike 3.0 license published by Creative Commons Corporation, a not-for-profit corporation with a principal place of business in San Francisco, California, as well as future copyleft versions of that license published by that same organization.
“Incorporate” means to publish or republish a Document, in whole or in part, as part of another Document.
An MMC is “eligible for relicensing” if it is licensed under this License, and if all works that were first published under this License somewhere other than this MMC, and subsequently incorporated in whole or in part into the MMC, (1) had no cover texts or invariant sections, and (2) were thus incorporated prior to November 1, 2008.
The operator of an MMC Site may republish an MMC contained in the site under CC-BY-SA on the same site at any time before August 1, 2009, provided the MMC is eligible for relicensing.
ADDENDUM: How to use this License for your documents
To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:
Copyright (C) year your name. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled ``GNU Free Documentation License''.
If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the “with…Texts.” line with this:
with the Invariant Sections being list their titles, with the Front-Cover Texts being list, and with the Back-Cover Texts being list.
If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.
If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.
[ << GNU Free Documentation License ] | [Top][Contents][Index] | [ >> ] |
[ < GNU Free Documentation License ] | [ Up : Top ] | [ > ] |
Appendix B LilyPond インデックス
Jump to: | A C D E F H I L M O P Q R S T U V W X |
---|
Jump to: | A C D E F H I L M O P Q R S T U V W X |
---|
[Top][Contents][Index] |
Table of Contents
- 1
lilypond
を実行する - 2
convert-ly
を使ってファイルを更新する - 3
lilypond-book
を実行する - 4 外部プログラム
- 5 LilyPond 入力ファイルの記述に対する提案
- Appendix A GNU Free Documentation License
- Appendix B LilyPond インデックス
Footnotes
(1)
Guile のステータスは .ly 処理後にリセットされません。そのため、Scheme 内部からいかなるシステム デフォルトも変更しないよう注意してください。
(2)
At least, this is possible in any LilyPond file which does not contain scheme. If there is scheme in the file, then the LilyPond file contains a Turing-complete language, and we run into problems with the famous “Halting Problem” in computer science.
(3)
このチュートリアルは Texinfo で処理されるため、上記の例とはレイアウトが少し異なります。
(4)
PDFLaTeX と LaTeX のどちらもすべての LaTeX ドキュメントをコンパイルできるとは限らないことに注意してください。これが 2 つ目の方法を説明する理由です。