2008年8月アーカイブ

　今回は小ネタである。

　上向き旗付き符尾の音符に付点が付く場合、付点は旗との衝突を避けるために通常よりも右にずらして付けられる。この設定は「ファイル別オプション−付点」の「上向き旗に付く付点の水平位置」にて行う。英語版Finaleのデフォルトファイルでは、ここの値が「0」に設定されているが、日本語版では、タイトなスペーシングを好む国内浄書の傾向を反映して、より符頭に近づけた設定になっている。

　しかし、浄書的なこだわりを言えば、符頭が線間の場合と線上の場合では旗と付点との位置関係が異なるので、個別に設定ができるようにして欲しいところだ。上記のような旗の先端が短めのデザインであれば、符頭が線間の場合にはまったく接触が起こらないので、なおさらである。

　さらに問題なのは、この付点が五線下の加線の符頭に付いたときのことである。符頭にいくら加線が付いて五線から遠ざかろうとも符尾は第３線から離れることはないので、ある位置の付点からは旗の影響をまったく受けなくなるのにもかかわらず、Finaleはかたくなに旗との間隔を維持しているのである。あらかじめ符頭に近づけてある日本語版の設定でも若干気になるが、とくに英語版の設定だと、付点が符頭から離れすぎてまったくおマヌケな楽譜になってしまう。

　Finaleの付点に関しては、もうひとつ明らかにプログラム上の設計の誤りと思えるものがある。
　浄書用語では、２度音程の和音の符頭が符尾を挟んで両側に付いた状態のことをクラスターと呼ぶ。現代音楽用語では、クラスターは密集和音のことを指すが、浄書では２和音においてもクラスターと呼ぶ(ちなみに、日本の浄書業界の符丁では「風鈴」と呼ばれる......なかなか風流である)。
　閑話休題、問題なのは上向き符尾のクラスターに付く付点である。旗なし音符の場合は、付点は単純に右側の符頭の端からの距離に置かれるのに、旗が付いた場合は、旗付きの設定が優先されてしまい(プログラム的には、これを文字通り旗付きの「フラグ」が立っている状態と言う)、右側の符頭はまったく無視され、付点は通常の旗付き音符と同じ位置に置かれてしまうのだ。その結果、より符頭に近づけた設定がなされている日本語版では、完全に付点が符頭と衝突してしまう。
　これについては、単純にプログラムを「クラスターの場合は旗の有無に関係なくつねに符頭の位置を優先させる」とすればいいだけの話なのだが、符頭との距離がルーズに設定してある英語版ではとりあえず符頭との接触は免れているから、開発者はこのプログラム上の欠陥に気付いていないか、あるいは、気付いていながらあえてルーズな設定でごまかしているのかもしれない。

　付点に関する設定は冒頭のダイアログのオプションしかなく、今のところあらゆる付点を自動的に最適配置にする設定はない。結局のところ、不適切な位置の付点はひとつずつ手動で修正していくしかない。私にスキルがあれば、これを一気に修正するプラグインでも作りたいところだが、そもそもこういうことは本体のプログラムで対応すべきものである。

　付点がお題目ということで、こんな問題点にも触れておこう。
　付点は符頭の数と一致しなくてはならない。一見当たり前のように思われることだが、しかし、Finaleはそうならない。

　このあたりになると、もはや難癖に近いものがあるが、セオリーはセオリーである。だが、下記のような極端なケースでは、セオリーを厳格に適用すると、かえって積み重なった付点のその異様さの方が目立ってしまう。左のFinaleのデフォルト状態はセオリーには反しているが、読譜者はこれを普通に付点４分音符と認識するだろうし、この付点を律儀に数えて「付点が足りぬからけしからん！」と憤慨する人はまずいないだろう。

　元来、浄書のセオリーとは、楽譜の読みやすさを追求して集大成したものである。しかし、楽譜には例外が付きもので、時としてセオリーに盲従するとかえって読みづらくなるというケースに遭遇することもある。セオリーに拘泥して読みやすさを犠牲にしたのでは、浄書の理念から言っても本末転倒である。
　もっとも、例外的なケースにおけるセオリーと読みやすさとのボーダーラインの判断は難しい。上記のケースでは、クラスターの何音まで付点を正確に付けるべきかということになるわけだが、私なら「瞬時に読み取れる数まで」という理由で、５個程度が妥当ではないかと考える。
　さらに言えば、「読みやすさ」は音楽のジャンルや、楽譜を使う人のレベルによっても異なってくる。このあたりの判断は、浄書というよりはむしろ編集の領域に入るが、浄書家と編集者のボーダーが曖昧になってきている現在、楽譜制作者は総合的なスキルを身に付ける必要性に迫られているとも言える。

　おっと、付点(Dot)にかこつけて小ネタのつもりだったが、話がどんどん敷衍してきたので、今日はこのあたりにしておこう。「楽譜の読みやすさ」については、Finaleとは一歩離れた話になるが、いつか機会があればお話ししたい。

　Intel Macと相性の悪いプラグインの記事でも触れた「コーダ切れの作成」プラグイン。このプラグインが付属したのはFinale 2006。じつにFinaleが産声を上げてから17年目のことである。それまでは、コーダ切れのレイアウトを作成するにはとても面倒な作業を行う必要があった。楽譜表記としては極めて一般的な「コーダ切れ」の作成に長年不便を強いられていたことに対して、「コーダ社(MakeMusicの当時の社名)だけに『コーダ切れ』は縁起が悪いから、あえてコーダ切れをさせないようにしているのでは？」などと揶揄される始末だった。

　さて、この「コーダ切れの作成」プラグインの搭載のおかげで、確かにコーダ切れレイアウトの作成は容易になったのだが、そもそも、Finaleにおけるコーダ切れレイアウトの考え方には根本的な設計上の問題があり、一見上手く処理しているように見えても、蓋を開けてみればいろいろな矛盾を抱えていることが分かる。

　本来、コーダ切れとは、ひとつの組段の途中に空白が挿入されたものと考えるべきものである。これはコーダ表記の変遷をみてみるとよく分かる。
　コーダ部はもともとa.のように書かれていたものが、コーダ部の前後には音楽的な脈絡はないので、それを明示するためにb.の表記が現れる。さらにそれを強調したのがc.の表記なのだが、もとより既成の五線紙の上に音符を書くしかない作編曲家にこの表記は不可能なので、c.の表記は自ら自在に五線を引くことの可能な浄書家ならではの発想だと言えよう。

　さて、Finaleの場合、分断された五線はあくまで別々の独立した組段なので(下図の組段番号参照)、コーダ切れを作成後に「組段の均等配置」を行うと思わぬ結果となってしまう。

　ひとたびコーダ切れレイアウトを作成してしまうと、小節割りの変更等でコーダ部が段頭になり、コーダ切れが必要でなくなった場合に、もとの１本の組段に戻すのは少々面倒である(上記の「組段の均等配置」を逆に利用するのが近道だが)。

　さらに、コーダ切れの前後の小節割りを変更したり、スペーシングが大きく変化するような修正を行った場合、コーダ切れを挟んだそれぞれの組段の左右マージンは自動的には調整されず、スペーシングバランスが崩れたままになってしまう。こうなった場合、このバランスは手動で調整しなければならない。

　また、「組段の最適化」または「五線を個別に移動可能にする」コマンドを行って五線の間隔を組段ごとに独立して変更可能にした状態で、コーダ切れの部分のどちらか一方の組段の五線の間隔を調整した場合、浄書的にはもう一方の組段の五線間隔もそれに追従しなければならないが、Finaleの場合は互いに独立した組段なので、当然のことながら追従はしてくれず、自己責任において左右の五線の垂直位置を揃えなければならない。

　以上のことから、「コーダ切れの作成」プラグインは、小節割り、五線間調整、段間調整等のすべてのレイアウトが決定した後に使用するのが望ましいということになる。

　ちなみに、Finaleのライバルソフト、Sibeliusのコーダ切れレイアウトの仕様はじつに理にかなっている。Sibeliusでは１段の五線が何本に分断されようと、あくまでひとつの組段として扱われるため、上記で述べてきたような問題は一切生じない。さらに、コーダ切れを元のつなげた状態に戻したい場合もじつに簡単だ。コーダ開始部分の左小節線を左にドラッグして直前の右小節線に重ねて離すだけで自動的につながるのだ。このインターフェイスはじつに小気味よく、初めて体験したときは思わず笑みさえこぼれてしまう。これを体験してからFinaleのコーダ切れに対面すると、何とも憂鬱な気分に陥ってしまうのである。
　そこまでSibeliusの肩を持つのであれば、Sibeliusに鞍替えすれば？と思われるかもしれないが、逆にFinaleに簡単にできてSibeliusにできないこともたくさんある。どちらにも長所があり短所もあるのだ。

　Finaleがコーダ切れをSibeliusの仕様に作り替えようとすると、おそらく抜本的な設計を見直さなければならなくなり、それに費やす経費と時間を鑑みると、事実上改変は不可能なのではないかと私は睨んでいる。
　この「コーダ切れ」と似た状況にあるものに「小節をまたぐ連桁」がある。これもプラグインで一応簡単に実現できるとはいうものの、それはあくまで姑息的な手法であり、根本的な解決とは言い難い。

　Finaleは毎年コンスタントにバージョンアップを行っているものの、開発サイドは楽譜作成ソフトとしての根幹と言える記譜機能は完成したと考えているのか、最近のバージョンアップは枝葉的な機能の付加が中心で、記譜機能の目立った改善があまり行われていない。やや古い記事(サイトを閉じてしまったのかキャッシュしか残っていないが)であるが、海の向こうでは、このようなメーカー側の開発方針に不満を示したユーザーによる、Finale 2009の不買運動の呼びかけも一部で起こったようだ。ソフト開発の大変さは重々承知しているが、Finaleの開発者にはもうちょっと本腰を入れてもらいたいものである。