Finaleのここがダメ! の最近のブログ記事

 小節線をまたいでつながっている連桁は、楽典的には例外的な表記ということになるのだろうが、ベートーヴェンやブラームスといった古典楽曲にもしばしば見られる表記であり、近現代の楽曲においてはいたって普通に見られる表記である。楽譜ソフトにおいて、小節内の連桁をつなぐことと小節線を挟んだ連桁をつなぐことにさしたる差はなさそうに思えるが、ことFinaleの連桁にとって、小節線の存在は往時のベルリンの壁のごとく厄介な障壁のようだ。どうもFinaleは当初の設計段階より、連桁を小節線をまたいでつなぐことを全く想定していなかったフシがあるからだ。


BOB1.jpg


 現在Finaleでは、小節線をまたぐ連桁はプラグインを使うことで実現できる。いや、「実現したように見える」と言った方が正確かも知れない。このプラグインを使ってつなげた連桁、一見つながっているように見えるが、実際は小節最後の音と次の小節最初の音符がつながれているわけではない。これは、小節線をまたいだ部分を改行してみるとすぐにそのからくりが暴かれる。


BOB2.jpg

冒頭の譜例の2小節目を次の段に送ってみたところ


 逆に、改行にかかる部分をつないだ場合、その部分が一段に収まるように小節のレイアウトを変更すると、やはり妙なことになってしまう。


BOB3.jpg

プラグインを使って改行部分の連桁をつないだところ


BOB4.jpg

上記の状態から2段目の小節を1段目に繰り上げたところ


 この「小節線をまたぐ連桁」プラグインは、同一組段上の連続している小節と、改行にかかった部分では全く異なる処理をしていることが分かる。したがって、このプラグインは、すべての組段の小節割りが定まった上で使用するのが適切な使い方ということになる(もちろん、後から連桁をつなぎ直すことは可能)。

 さて、これを踏まえて今回のお題目である。
 小節線をまたぐ連桁がページをまたいでしまう場合はどうすればいいだろうか? このプラグインを使用するには、あらかじめ少なくともつなぎたい部分の両側の小節を選択しておく必要がある。しかし、1ページ単位でしか編集ができなかったFinale 2008まででは、そもそもページを挟んだ2小節を選択する術がない。2009から複数ページを同時に編集できるようになったので、この問題は解決と思いきや、実際にプラグインを実行すると、以下の謎めいたエラーが出て、結局つなぐことはできないままだ。


BOB5.jpg

ページを挟んで「小節線をまたぐ連桁」プラグインを実行するとエラーとなる


 聡明なユーザーなら、「スクロール表示にした状態でつなげばいいじゃないか」と考えるだろう。しかし、このプラグインはスクロール表示の状態でもつねに改行/改ページ位置を考慮した処理を行うので、残念ながら結果は同じである。


BOB6.jpg

スクロール表示の状態で「小節線をまたぐ連桁」プラグインを実行する


BOB7.jpg

改行部分とそうでない部分で処理が異なっている


 このプラグインが実装されたFinale 2004当時は、まだ1ページ単位でしか編集できなかったわけだから、このプラグインの設計者がFinaleが複数ページにまたがって編集されることを全く想定していなかったことも頷ける。これについてはおそらく設計者自身も既に気付いていると思われるので、近いうちに改善されると思われるが、いずれにせよ、現時点ではページをまたぐ連桁の処理については2008以前と状況は変わらないということだ。

 ページをまたいだ連桁をつなぐには、改行部分を1ページ内に収める必要があるが、これには2通りの方法が考えられる。


BOB8.jpg

このページを挟んだ部分の連桁をつなぎたい


a. ページあたりの組段配置を一時的に変更する方法

  1. 2ページ目の最上段を1ページ目の最下段に追い込む。または、1ページ目の最下段を2ページ目の最上段に追い出す。これには、レイアウト・メニューの「組段の均等配置」を利用すると便利。

  2. BOB9.jpg


  3. この状態で改行部分の連桁をつなぎ、組段を元のレイアウトに戻す。

b. 小節割りを一時的に変更する方法

  1. 2ページ目の最初の小節が1ページ目の最下段の1小節目に来るように、または、1ページ目の最終小節が、2ページ目最上段の最終小節に来るように、前後の小節割りを調整する。

  2. BOB10.jpg


  3. この状態で改行部分の連桁をつなぎ、小節割りを元のレイアウトに戻す。

BOB11.jpg


 なお、1ページに1つの組段しかないスコアは、「改行=改ページ」なので厄介だ。このプラグインが動作するには、改行を挟んだ組段を1つのページに入れることを考えなければならない。


BOB12.jpg



  1. まず、2ページ目の1小節目を1ページ目に追い込む。または、1ページ目の最終小節を2ページ目に追い出す。

  2. BOB13.jpg


  3. 「コーダ切れの作成」プラグインを使って組段を改ページ部分で分断する。

  4. BOB14.jpg


  5. 「コーダ切れの作成」プラグインを使うと分断部分は必ず複縦線になってしまうので、ここで通常の小節線に戻しておく。複縦線のまま連桁をつなぐと、後で通常の小節線に戻したときに複縦線の幅だけ連桁がはみ出してしまうのを防ぐためである。
     この状態で分断された組段部分の連桁をプラグインでつなぎ、小節割りと組段を元のレイアウトに戻す。

BOB15.jpg


 この「小節線をまたぐ連桁」プラグイン、Finaleの機能の裏ワザを駆使し、それは涙ぐましい努力でこの連桁処理を実現しているスグレモノなのだが、そのあたりはFinale User's Bibleに詳しいので、ここでは割愛する。問題なのは、このプラグインはあくまでサードパーティが提供しているものであり、Finale本体の正規の機能で連桁の連結を実現しているわけではないことである。このプラグインによる連結は、ちょっと編集を加えれば容易に瓦解してしまう姑息な手段に過ぎないのだ。
 「コーダ切れ」にも言えるが、このような楽譜としては基本的な表記を、Finaleは外部プラグインにずっと頼り続けるつもりなのだろうか?

 音楽初心者のブログや質問箱での質問で「ダブルフラットやダブルシャープってどうして必要あるの? ナチュラルで書けばいいのでは?」と訴えている人をしばしば見かける。中には「私はダブルシャープなんか使いません!」と宣言しきっている人もいる。音楽理論を学べばダブルフラットやダブルシャープの必要性はおのずと理解できるはずだが、初心者にとって、これらの記号は庶民が安易に使っちゃいけない高尚な記号という感覚があるようだ。しかし、Finaleの話となるとちょっと事情は異なるようである。

 高速ステップ入力での音符入力中に「9」キーをタイプすると異名同音の切り替えができることはご承知のとおりだろう。ところで、1つの音に対する異名同音は2種類とは限らない。下の譜例では、縦に並んだ音はそれぞれ異名同音の関係にある。しかし、Finaleの異名同音切り替えは黒で示された音符同士にしか切り替わらないのだ。(なお、異名同音は理論上は重々変(嬰)音、重々々変(嬰)音......と存在するが、きりがないのでここでは一般的な重変(嬰)音までとする。ちなみに、Finaleは重々変(嬰)音以上の変化記号もサポートしている。)


Enharmonic1.jpg

 C音に対してはBシャープ音、B音に対してはCフラット音にしか切り替わらず、それぞれのもうひとつの異名同音であるDダブルフラット、Aダブルシャープには切り替わらない。使用頻度の少ない重変音・重嬰音より、変音・嬰音への切り替えを優先させたというのは理解できる。しかし、異名同音が重変音と重嬰音しか存在しないD、G、A音については、使用頻度に優劣は付けられないはずなのに、Finaleではダブルフラットにしか切り替わらないのだ。

 この仕様のおかげで、シャープ系の調にて「異名同音の表記」を「シャープを優先」とし、入力時にちゃんとダブルシャープで表示された音でさえ、ひとたび異名同音の切り替えを行ってしまうと、2度とダブルシャープでは表示されなくなるのだ(「編集メニュー」の「異名同音の再表記」を行うと入力時の状態に戻るが)。


Enharmonic2.jpg

ダブルシャープの音を「9」キーで異名同音変換したところ


 以上のことから、MIDIキーボードを使って高速ステップ入力を行う際にダブルシャープを表示させたい場合、まず、五線上の実際に置かれる高さの音を入力し、その音にカーソルを合わせてダブルシャープになるまで「+」キーをタイプするしかないのである。これは、入力されたMIDI信号をどの音で表記するかという判断であるから、リアルタイム入力した場合(マイク入力も含む)や、MIDIデータをコンバートした際にも同様のことが起こりうる。

 では、どうして開発者は異名同音の切り替えを2音間のみに限定させてしまったのだろうか?
 例えばC音に対して、C→Bシャープ→Dダブルフラット→Cというように、存在する異名同音が順番に切り替わったとしよう。これが2和音になると、1つの音に対する異名同音が3種類として、3×3=9通りの異名同音の組み合わせが存在することになる。3和音では3×3×3=27通り、4和音では3×3×3×3=81通りとなってゆき、もはや切り替えで希望の表記に到達させることは非効率だ。また、この切り替え方法では、2度音程の和音では音程の逆転も生じてしまい、音楽的に意味がない変換となってしまう。


Enharmonic3.gif

2音間のみの切り替えしか行われない現行のFinaleの仕様でも、
2度音程では音程の逆転が生じうる。

 こうしたことから、Finale開発者は、すべての異名同音を切り替える煩雑さよりも、切り替えを限定することによる簡便さを優先したのではないだろうか。それでも、D、G、A音の変換がダブルフラット方向のみに限定された理由の説明は付かないが......。

 ただ、この問題は単純に考えても、「9」キーをタイプする従来の変換に加えて、Shiftキー併用で反対方向の異名同音に変換という操作で解決するのではないかと思うのだが、何かプログラム的な不都合があるだろうか? もし機会があれば開発者に投げかけてみたい。

 今回は小ネタである。

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


augdot1.jpg

英語版のデフォルト設定

augdot2.jpg

英語版のデフォルト設定による付点の配置


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

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


augdot3.jpg

赤枠の部分の付点は旗の影響をまったく受けない


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


augdot4.jpg

日本語版のデフォルト設定では、旗付きクラスターに付く付点が符頭に接触してしまう


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


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


augdot5.jpg

左はFinaleのデフォルト状態、付点が1つ足りない。正しくは右のように置かれなければならない。


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


augdot6.jpg

左はFinaleのデフォルト、右は確かにセオリー通りだが......


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


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

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

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

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


codabrake1.jpg

古い楽譜や、現在も一部の出版社にはa.やb.の表記も見られる

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


codabrake2.jpg

この状態で「組段の均等配置」を行うと......

codabrake3.jpg

段違いになってしまう

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

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


codabrake4.jpg

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


codabrake5.jpg

左右の五線の高さが揃っていない

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

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

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

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

※ 09/6/27に記事追加

 最近の高機能のたいていの楽譜作成ソフトには、打楽器の楽譜上の音符と実際に鳴らす音源との関連付けを行う機能が搭載されている。Finaleの場合はパーカッション・マップがそれである。プレイバックに関与しない浄書専門のユーザーにはほとんど利用価値はないが、Finaleで楽譜を打ち込みながら音を確認したい大多数のユーザーにはなくてはならない機能である。
 打楽器の表記は、作編曲家によっても出版社によってもさまざまである。そのような多様なニーズに応えるひとつとして、パーカッション・マップには、特定の楽器に特定の符頭を割り当てるという機能がある。これを利用して入力すれば、自動的にシンバル系は×符頭、トライアングルは△符頭で表記させるといった使い方ができるようになる。


pmap1.jpg


 ところが、この一見便利に見える機能にも落とし穴がある。パーカッション・マップでは、各楽器について黒玉用と白玉用の符頭をそれぞれ定義できるのだが、通常の符頭を使おうと思った場合、白玉用符頭は1種類しか定義できないので、2分音符用の白玉か全音符のどちらか一方しか割り当てることができないのだ(通常、2分音符用の白玉が割り当てられている......上記ダイアログ参照)。この状態で楽譜を書くと、下のような奇妙な楽譜になってしまう。


pmap2.jpg

 これを修正するには、全音符のみを個別に変更するしかないのだが、まず、スコア全体の入力が完了した後、パーカッション・マップを使用しているパートのみを選択し、「ユーティリティ・メニュー(2007以前なら「ブロック編集メニュー」)>変更>符頭...」にて「検索:」「変更:」ともに「選択した符頭」に全音符を指定すれば簡単に一括変換できる。もちろん、選択範囲に別の符頭キャラクタの全音符を使用している場合は、その部分は選択範囲から外す必要があるが。


pmap3.jpg

pmap4.jpg

正しい表記になった

 浄書的には、通常の全音符に2分音符の符頭を使うというようなことは金輪際あり得ない。しかし、手書きの楽譜の場合、「白丸に符尾が付いていなければ全音符」という暗黙の了解があるから、とりあえずこの表記でも演奏現場で混乱が起こることはまずないという実態がいっそう事を曖昧にさせている。一般のユーザーに上記の修正法を周知させたところで、「別に読めるからいいじゃん」と煩わしさを理由に放置されるのが目に見えている。

 実際、作編曲家の書いたスコアがそのまま無批判に出版される傾向のある、ある分野の出版物にこの奇妙な記譜を頻繁に見かけるようになってきた。他の記事でも書いたが、特定のソフトの妙な仕様のせいで、正統的な書法が軽んじられ、妙な書法がスタンダードになってしまうことは残念なことだ。



09/6/27に追記

 同じ憂慮を抱いていたユーザーの声が届いたのか、Finale 2010からは、扱える符頭が全音符、倍全音符まで拡張された。メデタシメデタシ。しかし、旧ファイルの設定をそのまま受け継いで使っている場合は、全音符、倍全音符の部分は旧来通り2分音符の符頭のままで、自動的に全音符、倍全音符符頭にコンバートされるわけではないので注意が必要である。

 Finaleのスラーは、2002からフレックス・スラーという技術で描かれるようになった。それまでのスラーは、始点と終点の途中の障害物をまったく無視して描かれ、衝突の生じたスラーは手動で修正していくしかなかった。スラーの軌道上の障害物を避けるには高度な計算が必要で、スコア上のあらゆるスラーを瞬時に描くには相当のマシンパワーを必要とするわけだが、コンピュータの処理能力が、やっとそれをストレス無く描けるレベルになったからこそ実現できた機能と言えるだろう。


slur1.jpg

フレックス・スラーをオフにした状態

slur2.jpg

フレックス・スラーをオンにした状態

 このスラーのおかげで、浄書作業はずいぶん楽になったと思われるかもしれない。たしかに、普通に楽譜を書く分には、もはや衝突を気にしなくてもすむようになったわけだから、このスラーの功績は大きいと言えよう。だが、じつは、プロの浄書家の間ではこのフレックス・スラー機能はほとんど使われていない。なぜか。

 このフレックス・スラー、音形や障害物の突出具合によっては、スラーが必要以上に大きくふくらんでしまうことがある。


Slur3.jpg

下段のスラーは、臨時記号との衝突を避けたためにこのようにふくらんでしまった。

 五線間の狭いレイアウトでは、このようにふくらんでしまったスラーはかえって場所ふさぎになる。もちろん、そのようなスラーも手動で修正することも可能だが、フレックス・スラーは一旦手を加えてしまうと、もはやフレックス・スラーとしては機能せず、旧来のスラーと同じ扱いとなってしまう。

 もっと困った問題がある。フレックス・スラーは表示倍率によって形状が変わってしまうことがあるのだ。


Slur4.jpg

適切な形をしているスラーも......

Slur5.jpg

表示倍率を変えるとまったく違う形になることがある。

 どうやら、フレックス・スラーは描画のたびにスラーの軌道を再計算しているらしく、衝突を判断するしきい値の微妙な誤差によって描画結果が大きく異なることがある。これで怖いのは、ディスプレイ上では適切な形をしているスラーが、印刷やデータ書き出しの際に形が変わってしまうことだ。これでは楽譜としての品質の保証ができず、浄書家としては仕事にならない。結局のところ、プロとしては、このような不安定な機能に頼らず、フレックス・スラー機能をオフにして、従来通りスラーを手動で固定していくしかないのだ。

 では、このフレックス・スラー機能は何のためにあるのか?

 フレックス・スラー機能をオフにすれば、冒頭の譜例でもお分かりのように、あちこちでスラーの接触や衝突が発生する。浄書的にはこれらの衝突はNGであるから、浄書家はこれらを逐一手動で修正していくことになる。一方、一般的なFinaleユーザーがこんな修正作業を望むだろうか? もっと純粋に楽譜入力だけに専念したいはずだ。実際、このフレックス・スラーが導入される以前のFinaleで書かれた楽譜の多くに、スラーの接触や衝突が見受けられた。結局、楽譜情報が判読不明になるようなよほどの衝突でなければ、多くの人は、多少の接触や衝突は放置してしまうのではないだろうか。
 
 浄書家のレベルでは、スラーが接触や衝突を回避することは必要最低条件であり、なおかつ均整が取れた美しいスラーを描くことが求められる。そういう意味においては、冒頭のフレックス・スラーをオンにした状態で描かれたスラーも、とりあえず衝突を回避したというだけであり、美しいスラーというレベルではまだ及第点ではない。
 とはいえ、フレックス・スラーを使用した場合でも、問題となる不用意にふくらんでしまうスラーは、スラー全体から見たらほんの一部だろう(曲の性格によっては、問題が生じる確率が高くなることもあるだろうが)。それは、フレックス・スラー機能を封印することによって生ずる接触や衝突のリスクに比べれば大した問題ではない。一般ユーザーから見れば、フレックス・スラーはそれでも十分な機能なのである。それはちょうど、カメラにおいてプロが絞りやシャッター速度を長年の経験と勘に基づいてマニュアルで調整するのに対して、一般の人がオート露出機能を使うのと同じことだ。

 楽譜浄書が手書きで行われた時代、「スラー引き10年」と言われていたように、美しいスラーを描くことには相当の熟練を要した。楽譜浄書が完全にコンピュータ製作に置き換わった現在でも、美しいスラーを描くことはそれなりの技術とセンスを要する。コンピュータが何も手を加えずに自動的に理想的なスラーを描いてくれる日は、もう少し待つ必要がありそうだ。

 と、この原稿をもたもたと書いているうちに、海の向こうでは、最新版Finale 2009のアナウンスがあった。記事を読んでみると、2009では上記のフレックス・スラーの不安定さが完全に解消されたようだ。これは、我々浄書家にとっても多少の福音となるか......。

 次の譜例をご覧頂きたい。極めて普通に見られるリズムだが、じつは、Finaleはこの楽譜を書くことができない(正確に言えば、書けなくはないのだが、面倒な作業を必要とする。詳細は後述)。意外に思われるかもしれないが、これもFinaleの変な仕様のひとつだ。


a. beampattern1.jpg


 Finaleには、上記の譜例のような16分音符以下の連桁が休符を挟む場合の、内側の連桁をどう処理するかというオプションがある。


beamoption1.jpg

 このオプションをオンにすると、16分音符同士の内側の連桁はつながれるが、つながる相手のいない不完全連桁まで伸びてしまう。


b. beampattern2.jpg

 一方、このオプションをオフにすると......


beamoption2.jpg

 左側のパターンの不完全連桁の方は正常だが、16分音符同士の内側の連桁は分断されてしまう(そういうオプションなのであたりまえだが)。


c. beampattern3.jpg

 しかし、そもそもc.の右側のような連桁パターンはありえるのか? 少なくとも、信頼のおける老舗の出版社の楽譜ではこの形はお目にかかった記憶がない(しらみつぶしに探せばあるのかもしれないが)。普通に考えても、手書きで楽譜を書く場合、わざわざc.のような面倒な書き方をする人はいないだろう。浄書の書法もそのルーツは手書き譜にあることを考えれば、このパターンの場合も、内側の連桁がつながったa.(b.)が本来の形と考えるのが自然である。

 じつは、この内側の連桁をつなぐオプションはFinale 2000から設けられたもので、それまでのFinaleでは無条件でc.のパターンになっていた。a.のように内側の連桁をつなぎたければ、「連桁伸縮ツール」でちまちまと伸ばしていくしかなかったのだが、この作業を疎んじた人、あるいは浄書のセオリーに疎い人は、c.の状態の楽譜をそのまま世に出した。90年代からc.のパターンが巷で目に付くようになったのは、Finaleにもその一因がありそうだ。

 では、こんなオプションなどわざわざ設けずに、デフォルトで無条件でつながるようにすればいいじゃないかと思われるだろうが、そうもいかない事情がある。もしそうした場合、今度は2000以前に「連桁伸縮ツール」を使って調整した連桁が正しく表示されなくなるのだ。つまるところ、このオプションは過去のデータと互換性を取るためにだけに存在しているのである。Finaleには、このような過去の負の遺産を現在までずっと引きずっている部分があり、それがユーザーを混乱させる一因にもなっているわけだが、このあたりについては、またの機会に改めて述べることにする。

 というわけで、このオプションは本来なら常にオンにしておくべきなのだろうが、そうするとなぜか、b.の左側の連桁パターンのような楽譜としてあり得ない表記を生じさせてしまう。楽譜中に一方のパターンしか出てこないのであれば、そのパターンが正しくなる設定を選んでおけばいいが、両方のパターンが混在する場合、一方を正しい表記にしようとすれば、もう一方の表記が正しくなくなるという、「こちらを立てればあちらが立たず」状態になってしまうのだ。

 実際、この問題に遭遇した場合は、次のいずれかの方法で修正するしかない。


  • チェックをオンにした状態(b.)......「連桁分断ツール」を使って、不必要に伸びた不完全連桁を切断し、「特殊連桁ツール」を使って、残った断片を8分音符の連桁の位置に重ねて隠す。

  • チェックをオフにした状態(c.)......「連桁伸縮ツール」を使って不完全連桁を相手側の位置まで伸ばす。

 どちらの方法を使うかは、修正を要するどちらの連桁パターンが少ないかで判断するしかない。このあたりはFinale User's Bibleに詳細な手順が載っているので、興味のある方はそちらをご覧頂きたい。 

 現在もなお、正統な形であるa.の状態にするには上述のとおり面倒な作業を必要とする。しかし、浄書家ならともかく、一般的に作編曲でFinaleを使う人にまでこの作業を強いるのは酷なことだ。結局のところ多くの人は、あり得ない表記を引き起こすb.を避けて、それよりはまだましということでc.のスタイルを選択することになる。
 一定のシェアを持った特定のソフトの妙な仕様のせいで、正統的な書法が軽んじられ、妙な書法がスタンダードになってしまうことは残念なことだ。

 Finaleが高度な楽譜編集機能を備えているソフトであることは論を待たないが、そのFinaleにも、こんな基本的な楽譜表記のルールも反映していなのか、というような仕様が結構見受けられる。このあたりの話題は「Finaleのここがダメ!」のカテゴリでまとめていくつもりだが、おそらく、このカテゴリが一番充実してしまうのでは、と今から苦笑している。それはまるで「Finale叩き」の様相を呈してくるかもしれないが、それもFinaleに対する愛情の裏返し、Finaleに対するエールだと受け止めていただきたい。

 さて、その第1弾は休符の垂直位置である。
 複声部の場合や、単声部でも連桁グループの内側に置かれる休符は本来の定位置(ホームポジション)から上下にずらして置かれる。このずらし方にはルールがある。
 例えば8分休符の場合、ケルン(黒玉の部分)の位置は五線内においてはつねに線間になければならない。ところがFinaleでは、休符も音符と同様に2度ずつ上下に移動させることができるので、結果的にそのルールに反した誤った位置にも配置できてしまう。


restpos1.jpg

×印が誤った位置。▼印はホームポジション。
△印は微妙な位置だが、可能なら避けたいところ。

 なぜこれが誤った位置なのか理由がよく分からないという人は、休符に付点を付けてみれば一目瞭然だろう。


restpos2.jpg

 すなわち、休符は、五線内においてはホームポジションから3度ずつ1間単位で上下しなければならない。一方、五線の外ではこの制約はない。


 なお、ケルンの数は8分休符以下ではひとつずつ増えていくから、当然のことながら制限される配置(×印)もひとつずつ増えていくことになる。


restpos3.jpg

16分休符の配置

restpos4.jpg

32分休符の配置

 ところで、楽譜はいつも五線とは限らない。打楽器のように1〜数本線で表記されるものもあれば、ギターのタブ譜のように6線以上で表記されるものもある。それぞれの本数によって、制限される範囲も異なってくる。

 休符に限ったことではないが、このような配置ルールを言葉で表すのはじつにたやすい。「見にくくならないように」......それだけのことなのだ。しかし、そういったかつての浄書職人が長年かけて築き上げてきた感覚的なロジックをコンピュータで制御するのは意外と面倒なことなのかもしれない。とはいえ、スペーシングや、Human Playbackといったもっと複雑な制御を実現している現在、この程度の制御がなおざりにされているのはやはり片手落ちと言わざるを得ない。

 私たちは、Finaleの休符が誤った位置に置かれる可能性があることを承知した上で、誤った配置にならないような設定を行う等、つねに細心の注意を払っているわけだが、このことを知らずに無造作に使っていると、Finaleはいとも簡単にぞんざいな楽譜を作り上げてしまうソフトだということを知っておいて欲しい。

このアーカイブについて

このページには、過去に書かれたブログ記事のうちFinaleのここがダメ! カテゴリに属しているものが含まれています。

前のカテゴリはバグ情報 です。

次のカテゴリはTIPS です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。