Finaleにまつわるエトセトラ

　以前の記事「調号にまつわるエトセトラ」の冒頭の繰り返しになるが、Finaleは高機能の楽譜作成ソフトでありながら、「未だにこんなこともできないの？」という部分がまだまだたくさんある。そんな中から今回は臨時記号にメスを入れてみることにする。
　少々言い訳がましくなるのだが、じつはこの記事は「調号にまつわるエトセトラ」の続編として書き進めていたものである。ただ、例年ならそろそろFinaleの次のバージョンがリリースされる時期でもあり、書こうとしていた問題点が新バージョンで解決していた場合、記事としての価値はなくなってしまう。そこで新バージョンのリリースを待っていたわけだが、今年に限ってその新バージョンはなかなかリリースされず、結果としてその間はブログの更新ができなかったことをお詫びしたい。
　結局のところ、先日リリースされたFinale 2012では、幸か不幸か記譜部分についてはこれと言っためぼしい機能の更新はなく、これで晴れて気兼ねなく問題点が指摘できることになった(それはそれで不幸なことではあるが)。

無駄なスペースの多いFinaleの臨時記号配置
　臨時記号はそれ自体がスペーシングに大きな影響を及ぼす存在である。過去の浄書家は臨時記号をいかに少ないスペースに無駄なく効率的に配置するかに腐心し、そのセオリーを確立してきた。その点、Finaleの臨時記号の配置処理はまだまだ不完全である。

　和音に複数の臨時記号が付く場合 、臨時記号同士が重ならないように配置しなければならないわけだが、Finaleには何度の音程まで臨時記号をずらして衝突を回避するかという設定がある。「ファイル別オプション - 臨時記号」にある「垂直方向の衝突を回避する音程」という項目がそれだ。デフォルトでは「６」に設定されているのだが、臨時記号のデザインはその種類によってそれぞれ異なるので、その組み合わせによっては６度以下でも衝突は発生しない。たとえばダブルシャープ同士の場合、Finaleのデフォルトの「６」では衝突の発生しないものまで避けてしまい、無駄なスペースを発生させている(２つ下の譜例参照)。ダブルシャープ同士の場合に限ってみれば、ここの設定は「３」でよいことになる。
　ところで、この項目にある「(半音単位)」というのは「(度数)」の誤りではないのか？

　さらには、Finaleには「和音に付く臨時記号同士の間隔」という項目があるが(下図のa.の距離)、そもそもこの考え方自体がナンセンスである。一般的な臨時記号の配置セオリーでは、なるべく少ないスペースに収めるべく臨時記号同士を積極的に組み合わせて配置の順番を工夫しているのに対し、Finaleのように横方向に一定間隔に並べていたのでは、どんな順番に並べたとしても臨時記号全体が占めるスペースに変化はなく、配置の順番など全く意味がなくなってしまっている。

　和音に付く臨時記号同士の間隔については、Finaleのように一律な数値で固定されるものではなく、 臨時記号の組み合わせによって変化すべきものなのである。次の譜例の下段は無駄なスペースを埋めるべく、手動で臨時記号を調整したものである。

　もうひとつは、下向き符尾のクラスターを含む和音に付く臨時記号の問題点である。クラスターとは一般的な音楽用語では密集配置の音を意味するが、浄書用語に限っては２度音程の和音のことを指す。下向き符尾の場合、クラスターの下側の符頭は符尾の左側に飛び出して付く。臨時記号は飛び出した符頭を避ける必要があるが、Finaleでは臨時記号は飛び出した符頭の左端を基準に配置されるので、結果として飛び出した符頭に影響されない位置の臨時記号まで不必要に避けてしまい、ここでもスペースを浪費している。このような臨時記号は符頭の飛び出しとは関係なく本来の位置に配置されるべきである。

　和音に付く複数の臨時記号の配置については、和音の状況によってフレキシブルな対応が求められるのだが、現在のFinaleはどのようなケースにおいても一律なセオリーでしか対応できない。

　これまでの説明を聞いている限りでは、別に臨時記号が衝突をしているわけでもなし、この程度のスペースなんて気にすることではないのではと思われる方もいるかも知れない。しかし、次の譜例をご覧いただければ、なぜここまでスペースの調整にこだわるのかが理解いただけるのではないだろうか。

　ところで、上記の臨時記号に関するオプションには、「臨時記号と符頭の間隔」と「和音に付く臨時記号同士の間隔」の値を「0」にして保存し、そのファイルを再度開くと、どちらも勝手に「8EVPU」になってしまうという不可思議なバグがある。

問題点山積の複声部の臨時記号処理
　これまで述べてきたことは、どちらかというと浄書家の視点からの問題点であり、実用面からすれば、少々見てくれは悪いとしても楽譜として破綻しているわけではない。しかし、Finaleには実用面において支障を来すような問題も抱えている。

　臨時記号に関するオプションの中に「異なるレイヤーの臨時記号を自動的に避ける」という項目がある(上記のダイアログ参照)。どういう機能なのかは次のような楽譜を作成し、このオプションをオフにしてみれば一目瞭然である。ちなみに、高速ステップ入力枠内では編集中のレイヤーしかアクティブにならないので、このオプションをオンにしていても、臨時記号はオプションをオフにした状態の配置で表示される。

　意外に思われるかも知れないが、じつはこのオプションはFinale 2004になってやっと実装されたものである。それまでは複声部の臨時記号はつねに右側の状態になり、衝突した臨時記号は「道具箱ツール」の中の「臨時記号調整ツール」でひとつひとつ修正していくしかなかった。
　では、なぜ「臨時記号の衝突を自動的に避ける」などという当たり前のようなオプションがわざわざ存在するのかという疑問が生じるが、それにはやむを得ない事情がある。衝突した臨時記号を手動で修正した2003以前のファイルを2004以降で開いた際、臨時記号の自動衝突回避が無条件で機能すると、回避されたポジションにさらに修正によって移動させた分の距離が加算され、かえって不自然な配置になってしまうのである。つまり、このオプションは旧来のファイルで行われた手動による修正状態を保持するためだけに設けられたものなのだ。
　ところでこのオプション、オン/オフをする際に手動による調整が解除される旨のアラートが表示される。これで旧ファイルの手動調整を一気にリセットできるので、万事解決するじゃないかと思いきや、そうは問屋が卸さない。Finaleの臨時記号の配置処理にはまだまだ解決すべき問題が残されており、せっかく修正したものがリセットによってかえって不適切な状態になってしまうこともあるからだ。リセットによって完璧な配置になるのであれば、そもそもこんなオプションなんか要らないわけだが、これを残さざるをえないところにFinaleの苦しい胸の内が伺える。
　じつは、Finaleには未だにこういった過去の不完全な設計とのつじつま合わせをするためだけのオプションがいくつか存在し続けている。このあたりはあらためて記事としてまとめてもよいと思っているのだが、Finaleは過去の遺物とも言えるこういったオプションを一体いつまで継承し続けていくつもりなのだろうか？　百歩譲って、過去のファイルとの互換性のために必要であるとしても、せいぜい「プログラム・オプション - 開く」の旧バージョンのファイルを開く際のオプションとしてひっそりと存在させるべきで、不用意に触ってしまう可能性のあるユーザーの目に付く場所に置かれる類のものではないと思う。

　前置きが長くなってしまったが、次の例を見ていただきたい。
　符頭を共有する複声部に付く臨時記号は共有されるものだが、Finaleではなぜかご丁寧にそれぞれの声部に付く臨時記号同士を避けてしまい、結果として二重に表示されてしまうのである。シャープやナチュラルについてはありえない表記なので、その異常さにすぐに気が付くが(※注)、たまたまフラットが単独で現れた場合、ダブルフラットに誤読されてしまう危険性がある。これを回避するには、どちらかの声部の臨時記号を手動で非表示にするしかない。

※注：古い時代には、ダブルシャープをシャープを二つ続けて書く書法も一部で存在した。

　皮肉なことに、上記の「異なるレイヤーの臨時記号を自動的に避ける」のチェックを外すと、臨時記号はぴったりと重なって表示され、見た目としては正しい表記になる(プリンタによっては若干太く印刷されることがある)。しかし、楽譜中の複声部に付く臨時記号がこのケースしかないといったレアな状況でもない限り、この表記のためだけにこのオプションを利用するというのもそもそも無理がある。

　Finaleには、下声部にクラスターが含まれている和音に付く臨時記号が正しい位置に表示されないという問題もある。
　次の譜例では上段がFinaleのデフォルトの状態であるが、臨時記号の配置が不自然である。この下声部の左側に飛び出した符頭が上声部の符頭の左端に揃うように下声部全体を右にずらすと、下段のように臨時記号の配置は正しくなる(緩い配置であることについては不問とする)が、もちろん音符の配置としては誤りである。

　つまり、下声部の臨時記号について、Finaleは左側に飛び出した符頭の幅を計算に入れることをすっかり忘れているのである。
　上段の状態を放置するわけにはいかないので、当然臨時記号は手動で修正する必要がある。さて、将来この問題が解決されたとき、それまで手動で修正した臨時記号はどう扱うのか？　ここでこの項の冒頭で述べた問題が再燃する。Finaleはまた新たに「異なるレイヤーの２度和音に付く臨時記号を解決する」などというオプションを付けるのだろうか？

　さらには、「異なるレイヤーの臨時記号を自動的に避ける」というオプションは、じつは「看板に偽りあり」である。
　次の譜例では、臨時記号の存在は全く無視されている。

　もっともこの例に限って言えば、実際は臨時記号だけの問題ではなく、旗や付点についても同様であり、つまるところ、Finaleは異なるレイヤーの間でのエレメントの衝突については全く考慮がなされていないということになる。

　現時点ではこの衝突を自動的に避ける手段はなく、手動でスペースを確保して調整するしかない。確保の方法はいろいろ考えられるが、それだけで一つの記事が書けそうなので、そのあたりについてはいずれかの機会に預けたい。

　今回の問題点は、バグというより単なる設計ミスの範疇に入ると思われるが、世界標準を標榜する楽譜作成ソフトとしてはかなりお粗末な状態だと言えはしまいか。このFinaleの不完全な設計のせいで、多くのユーザーが不毛な修正作業を強いられるか、もしくは修正されないままの不適切な楽譜が世に出回り続けるかのどちらかである。開発元にはこれらの根本的な解決に本腰を入れてもらいたいものだ。

　ここ数年は梅雨の頃に発表されていたFinaleの次期バージョンだが、2012についてはなかなかリリースされなかった。リリースが遅れることについては開発元から早くからアナウンスされていたが、その理由については具体的には触れられておらず、ユーザーからは「ライバルソフトのSibeliusを凌駕する新機能が実装されたのではないか」、「いや、７月に発表されたMacintoshの新OS"Lion"に対応させているんだろう」、「会社自体がやばいんじゃないか」等々の憶測を呼ぶことになった。はたして秋も中旬に差しかかった頃、バージョン2012はそのヴェールを脱いだわけであるが、じらされたユーザーの期待に応えられるだけの新機能はあったのか？　早速今回も紹介してみよう。

Finaleも遂にダウンロード販売に
　Finaleは2012からはダウンロード販売になった(従前のパッケージ販売も平行して行われている)。MakeMusic社のサイトからダウンロード後、１ヶ月間は機能制限なしの製品版として試用できる。製品購入後シリアル番号を入手して認証を経ないと、１ヶ月を過ぎると印刷や保存ができなくなるといった仕組みのようだ。ただし、付属のGarritan音源だけは認証を経ないとダウンロードできないようになっている。もちろん、すでにFinaleを持っている人は2012で新たに追加された音色が使えないだけで、旧来のGarritan音源はそのまま利用可能である。
　このダウンロード販売方式への移行は、Appleの提唱するAppStore経由でのアプリケーションソフトの販売方式を見据えたものと思われる。
　なお、日本語版がどういう販売形態を取るかは現時点では不明である。

スコアの属性とプレイバック音源を一元管理できるScore Manager
　Finale 2012では、スコアの管理を「ファイル情報」と「楽器リスト」と「五線の属性」ダイアログの一部が統合されたScore Managerというフローティングウィンドウで一元的に行うようになった。

　Instrument List(楽器リスト)のページでは、上側に従来の楽器リストが、下側にこれまで「五線の属性」ダイアログで行っていた楽器名や移調等の設定が配置されている。これに伴い、「五線の属性」ダイアログからはこれらの機能が消滅している。
　楽譜を新規に作成する場合は、従来通りセットアップ・ウィザードを利用すればよいのだが、Score Managerはセットアップ・ウィザードの機能も備えており、ここで楽器の追加や削除、並び替えを行うことができる。五線の追加は"Add Instrument"から選択、削除はリストの右端の×印をクリック、並び替えはリストの左端のリストアイコンまたは楽器名を掴んでドラッグとインターフェイス的にも分かりやすくなっている。これらの編集は即座に楽譜に反映されるので、実際に楽譜を見ながら作業が可能だ。ここでは楽器ごとにプレイバック音源のデバイスを設定することもできる。

　ユニークな新機能として、同じパートの奏者の序列表記を５つのフォーマットから選択できるようになっている(上図"Auto-Number Style"ポップアップメニュー参照)。ただし、セットアップ・ウィザードから新規作成した場合は、従来通り無条件で一番上の"Instrument 1, 2, 3"のフォーマットになるので(Violinについては"Instrument I, II, III"のフォーマットになる)、他のフォーマットに変更したい場合は、Score Manager上で１パートずつ手作業で変更しなければならないのが難点だ。せめて全体を一括して変更する手段を用意するか、もしくは、セットアップ・ウィザードの方にもフォーマットの選択を用意してもらいたかった。次のバージョンかアップデートでの改善に期待したい。

パート中の楽器変更がより簡単に
　例えば、オーボエパートが曲の途中でイングリッシュホルンに持ち替える場合、これまではイングリッシュホルンの移調設定や楽器名の設定を仕込んだ楽譜スタイルを作成して、それを持ち替え部分に適用させる必要があった。さらに、プレイバックに対応させるには、音色パッチないしはMIDIチャンネルを変更する「仕込み」を発想記号で作成し、持ち替え部分に貼り付ける必要があった。2012からはこのような楽器の持ち替えについても、プレイバックの設定ともども簡単に管理できるようになっている。
　操作はいたって簡単である。例えば、オーボエパートの22小節から29小節をイングリッシュホルンに持ち替えたい場合、その楽譜範囲を選択し、ユーティリティメニューに新設された"Change Instrument..."を選択すると現れるダイアログにて変更したい楽器を選択するだけである。OKをクリックした瞬間、楽器名や移調表記も即座に楽譜に反映される。

　Score Managerにてオーボエパートの▲印を倒して内容を確認してみると、そこにはイングリッシュホルンが追加され、チャンネルやパッチも適切に選択されていることが分かる。"Start"欄の数値はその楽器変更が開始される小節を示し、変更を修了した次の小節で自動的に元の楽器に戻るように設定されているという按配である。

　なお、楽器の変更や移調設定についてはScore Managerで一元的に管理することになったので、「五線の属性」ダイアログの設定を踏襲している楽譜スタイルにおいても移調設定に関する定義はできなくなっている。したがって、楽譜スタイルで移調楽器を設定していた旧バージョンのファイルを開いた場合、その部分は自動的にScore Managerの該当パートに変更楽器として小節の範囲と共に追加されることになる。なお、楽譜スタイルにはプレイバックに関する設定は仕込めないので、追加された楽器のプレイバック属性については元のパートの設定がそのまま踏襲されている。もっとも、変更部分のプレイバックに関する設定は別途発想記号で仕込んであるだろうから、Score Managerでは特に何もしなくてもそのまま以前のプレイバックは再現できるはずである。
　この仕様変更に伴い、旧ファイルを開くと、移調設定が含まれていた楽譜スタイルは強制的に削除されるようだ。

Unicodeへの対応
　Unicodeはあらゆる言語の文字や記号を一元的に管理できる文字コードシステムだが、遂にFinaleもこれに対応した。これでキリル文字やハングル、中国簡体字等の文字入力、日本語においても「はしご高」や「土吉(つちよし)」等の異字体表現が可能になった。これに伴い、2011で発生していた日本語歌詞のクリックによる割り付けで、歌詞ウィンドウでハイライトされている文字と実際に割り付けられる文字が対応しないバグは解消された。

　「キャラクタの選択」画面で選択可能なキャラクタも、これまでの256キャラクタから、それぞれのフォントが持っているキャラクタの数に応じて拡張される。このキャラクタ選択方法は符頭等の変更にも有効なので、実用的かどうかは別として、楽譜中のエレメントとして使用できるキャラクタの選択肢は大幅に増えることになる。

　なお、「キャラクタの選択」画面では、日本語フォントについては、Mac版の場合、CIDフォントでは上記の通り仮名や漢字もリストに表示できるが、システムフォントのヒラギノをはじめとするOpenTypeフォントでは仮名や漢字部分はなぜかリストに現れない(下図)。このあたりがどういう仕組みになっているのかもう少し検証してみたいところだ。

　上記のような特殊な文字入力をふだん必要としない人にとっては、FinaleがUnicodeに対応したことの意義はあまり感じられないかも知れない。しかし、上記でも触れた歌詞編集におけるバグが解決されたことからも分かるように、Finaleがあらゆる言語に対応したということは、すなわちこれまで散々悩まされてきたFinaleの日本語環境固有のトラブルからの解放を意味し、これは結果的に日本のユーザーにとっても福音となるはずである。

新しいマクロ機能
　「知っておくと便利」的な機能だが、「−(ハイフン)」キーを押しながら操作すると、ツールごとの直近の操作を行ってくれるという繰り返し機能が追加された。
　例えば、アーティキュレーションツールである音符にアクセントを付けたとする。すると、次からは「−」キーを押した状態でクリックまたはドラッグするだけで目的の音符にアクセントが付くというものだ。直近の操作はツールごとに記憶されるようで、一旦発想記号などの別のツールで同様の操作をしてそのツールでの操作を記憶させた後、再びアーティキュレーションツールに戻って同様の操作をしてもちゃんとアクセントが再現される。
　すでにマクロが仕込まれているものについては、従来通りにそれぞれのマクロキーを使えばすむ話だが、マクロが仕込まれていない記号を付ける場合にはこの機能は重宝するかもしれない。
　ちなみに、JIS配列のキーボードでは「−」キーはShiftキー併用で「＝」キーに対応するので、機能としては憶えやすい。もっとも、あちらの開発者がJIS配列を念頭に置いてこのキーを割り当てたとは考えにくいので、これは偶然の産物だろうが。

久しぶりに追加されたプラグイン
　ここ数年、新たなプラグインのバンドルは途絶えていたのだが、久しぶりに３つの新たなプラグインが追加された。もっとも、そのうちの２つはバリエーションの違いといったもので、実質的には２つということになるが。

　まず１つは、ページ内の組段同士の間隔を調節するプラグイン。すでにFinaleにはページ・レイアウトメニューに「組段の均等配置」という似た機能があるが、このプラグインではページの上下に余白を加えたり、間隔の取り方をいくつかのパターンから選択できるようになっている。

　ただ、実際に試してみたが、スラーや加線の多い音符等の「五線からの飛び出し」を加味した配置が行われるわけでもなく、従来の「組段の均等配置」の機能との差別化は今ひとつ見い出せなかった。このプラグインの有用性についてはもう少し研究をしてみたい。
　ちなみに、いきなりv 2.00となっていることから、すでに何度かの改良を経たものであることがうかがえる。

　もう１つは、2011からバンドルされたAlphaNotesフォントによる符頭表記を、楽譜の任意の場所に適用させるというプラグインである。
　じつは、2011から用意されている楽譜スタイルの「Apply Finale AlphaNote Notenames※注」でも同様の機能が実現できるのだが、こちらは五線位置に１つの符頭を対応させる「特殊な符頭」機能を利用しているので、幹音にしか対応できず、派生音は無視されていた。

※注　英語版のデフォルトファイルMaestro Defaultの楽譜スタイルには"Apply Finale AlphaNote Notenames"と"Apply Finale AlphaNotes Solfege"の２つが用意されているのだが、なぜか日本語版2011のデフォルトファイルKousaku Defaultでは前者は削除されていて、後者のみ「AlphaNotes ソルフェージュの適用」として残されている。

　今回追加されたプラグインでは、「特殊な符頭」機能を使わず「符頭変更ツール」で一音ずつ対応させているので、派生音にも臨時記号付きで対応している点が大きく異なる。

　なお、AlphaNotesフォントにはダブルシャープやダブルフラット付きの符頭キャラクタは用意されていないので、これらの音程の符頭は文字の書かれていない通常の符頭キャラクタに変換される。

新たなフォントのバンドル
　2012には和声記号や通奏低音の表記用としてFinale Numericsフォントがバンドルされた。このフォントの特長は、文字幅０というギミックを使って同じ位置に複数の文字や記号を積み重ねることで、３段までの度数を通常のテキストとして表記できる点にある。これまでFinaleに付属していた通奏低音ライブラリはコードネーム機能を利用したものだったが、マニュアルによると、このフォントでは歌詞機能を利用するように勧めている。

　和声記号の様式は国や和声システムによっても異なり、このフォントであらゆるタイプの和声記号に対応できるわけではない。例えば、日本の和声書で一般的に見られるような、借用和音の借用される度数を上部に小さく載せる書法には対応できない。このような表記を行いたければ、和声記号を合成するか、もしくはストーンシステムから販売されている「和声記号フォントパック」を利用するしかない。

　また、譜例をご覧いただけるとお分かりの通り、Finale NumericsフォントはTimeフォントをベースに作られているため、外観をそれ以外のフォントに変更することはできない。

　もうひとつ、手書き風のFinale Copyist Textフォントがバンドルされた。このフォントは2010からバンドルされた記譜用フォントBroadway Copyistフォントに対応したものである。Jazz Textフォントほどポップではなく、フェルトペンで楷書された趣の書体である。なお、このフォントはJazz Textフォントと同様、スモールキャピタルフォントなので、コードネームとして使う場合、"Am"等の表記はできないことに留意する必要がある。

その他の新機能
・グラフィックの書き出しにPDFが加わった。

・Garritanサウンドに数種類の楽器が追加された。

・他人にデータを渡した際にもプレイバック音源が再現されるようにサウンドマップを用意した。

・追加したMIDIデバイスを即座に検出するようになった。

・MusicXML 3.0に対応した。

　以上、駆け足で2012の新機能について紹介したわけだが、確かに、Score Managerによる楽器管理をはじめ、細かな部分の利便性の向上に力を注いだことはそれなりに評価できる。しかし、このソフトの根幹とも言える楽譜作成の部分についてはほとんど進展が見られなかったことは残念の一言に尽きる。このブログでは、例年なら新バージョンのレビューには２回分を費やしていたのだが、今年に限っては１回で済んでいる点からも今回のバージョンアップ内容の乏しさをうかがい知ることができよう。例えば、楽譜エレメントの衝突回避策を講じたレイアウト整形などは、ライバルソフトに大きく水をあけられている感があり、その他にも楽譜作成ソフトとしてまだまだ改善すべき課題は多く残されているはずである。このあたりについては、本家のフォーラムにおいてもリリース直後からユーザーから失望の意見が多く寄せられていた。しばらくすれば日本語版もリリースされるだろうが、日本のユーザーの目には今回のバージョンアップはどう映るのだろうか。

　先日、Finaleの開発元であるMakeMusic社が、MusicXMLを開発しているRecordare社を買収するという発表があった。MusicXMLは現時点における楽譜表記のデファクトスタンダードであり、その技術を手中に収めることでMakeMusic社はこの業界の主導権を握ろうとしているのだろう。その意気や良しではあるが、それならそういうメーカーに相応しい楽譜作成ソフトを今後とも提供してもらいたいものである。

　Finaleは産声を上げて既に20年を越える老舗ソフトであり、非常に充実した機能を持っているのだが、このソフトの根幹とも言える楽譜作成部分には「未だにこんなこともできないの？」というようなものも残っている。今回はそんな中から調号に焦点を当ててみることにする。

モードチェンジを伴う転調時の妙な転調表記
　平行調関係にある調の調号は同じである。例えば、ニ長調とその平行調であるロ短調の調号はどちらもシャープ２つで付く位置も同じである。これは楽典のイロハとも言える部分だが、Finaleの場合、この見た目は全く同じ２つの調号は全く異なるものとして扱っている。その理由は、キーボード入力やMIDIデータからの変換の際に、臨時記号の付き方をそれぞれのモード(旋法)に応じて処理を行ったり、コードネームを度数表示にしてみると容易に理解できるはずだ。

　しかし、この仕様が思わぬところに影響を及ぼしているのである。

　一般的な転調表記では、調号の全く同じ平行調に転調する際に改めて調号を書くことはない。ところが、Finaleのファイル別オプションの「調号」の項を見ると、「平行調への転調時にも調号を表示」という項目がある。この項目は初期のバージョンから存在し、こういう設定があるということは、広い世界のどこかにそういう記譜を行う流儀があるという証左なのだろうが、私は未だにこの記譜にお目にかかったことはない。興味深いのは、以前の日本語版のデフォルト・ファイルではオフになっていたこの設定が、 Finale 2007以降はなぜかオンになっていることだ。なぜ設定を変更したのか日本語版の担当者にその理由を問うてみたいものである。
　加えて、その直下の「無効になる変化記号をナチュラルで表示」にチェックが付いていると、平行調に転調する際、一旦調号を消して再び同じものを付け直すというじつに滑稽な表記になってしまう。

　この不可思議な転調表記をさせたくなければ「平行調への転調時にも調号を表示」をオフにすればよいわけだが、これで万事解決というわけではない。
　一般的な転調表記では、シャープ系またはフラット系の同系同士の転調の場合、調号の変化記号が少なくなる場合は不要になる変化記号のみをナチュラルで打ち消せばよく、逆に変化記号が増える場合は新たな調号を付けるだけでよい(下図)。Finaleも長調−短調間のモードチェンジを伴わない転調の場合は一般的な転調表記になる。

　ところが、モードチェンジを伴う転調の場合、Finaleではやはり一旦すべての調号をナチュラルで打ち消した後、改めて新たな調号を付けるという不思議な表記になってしまうのだ(異なる系列への転調の場合は、モードに関係なくすべての調号を一旦打ち消す必要があるので、この問題は発生しない)。

　かといって「無効になる変化記号をナチュラルで表示」をオフにすれば、今度は打ち消しに必要なナチュラルまでもが非表示になってしまう。つまり、モードチェンジを伴う転調において、Finaleでは調号に関するいかなるオプションの組み合わせをもってしても、標準的な転調表記を行う術はないのである。
　この問題を解決するには、ひとつのファイル内では同系同士の転調の際にはモードチェンジを行わないより他に策はない。すなわち、長調で開始した曲は、途中の短調部分もその平行長調(短調で開始した曲ではその逆)で書き通すしかないのである。

　では、このことを知らずに入力してしまった場合はどうすればよいか？　これから編集を行う他人の作った楽譜がその状態になっているというケースもあるだろう。
　調号ツールでモードを統一したい調の部分全体を選択し、「調号」ダイアログにてモードを切り替えた後、「移調の設定」の「既存の音符はその音程を維持＞元の変化記号を維持」を選択した状態で移調を行えばよさそうだが、これは同じモード同士の移調の時にのみ有効のようで、モードチェンジを行った場合は、なぜか現在選択されている「異名同音の表記」に従った表記に強制的に変えられてしまう。これって「看板に偽りあり」ではないのか？
　じつは、Finale 2006までは、その下のオプションの「五線上の音符の位置を動かさずに変化記号を適用」を選択した状態でモードチェンジを行えば、臨時記号の表記も移調前の状態が保たれていた。ところが、2007以降では手動で異名同音変換を行った臨時記号については、その音のみが移調されるというバグが発生し(下記譜例参照)、臨時記号の表記を保持したままモードチェンジを行う術が全くなくなってしまったのだ。まさに踏んだり蹴ったり、泣きっ面に蜂である。

　Finale 2007といえばリンク・パート機能が追加されたバージョンである。このとき、スコア譜とリンク・パート譜とで異名同音表記を行えるように臨時記号の属性の仕様が変更されたらしい。その影響か「和音の分散」機能では、手動で異名同音変換を行った和音構成音が意図しない音に分散されるというバグが発生した。こちらのバグは後のバージョンで修正されたが、上記の移調時のバグの方は開発元も気付いていないのか、未だに放置されたままである。
　もっとも、移調範囲に手動で異名同音変換を行った臨時記号が無ければ、上記の移調方法は2007以降でもなお有効である。しかし、現実問題として異名同音変換が一切行われていないケースというのは非常に限られている。結局のところ、既に入力の完了している楽譜に対して後からモードチェンジを行う場合は、臨時記号の表記が勝手に変更されてしまうというリスクをつねに意識しておかなければならない。このバグについては早急に修正してもらいたい......というより、この臨時記号のバグはバグとして、そもそも上記の調号のナチュラル表記の問題さえ解決してくれさえすれば、こんなことに頭を悩ます必要はないのであり、まずはそちらを優先して対応してもらいたいものだ。

転調とリピート開始が同時に行われる部分の不思議な転調表記
　一般的に転調は新しい楽節の開始部分で行われることが多いので、反復記号の開始と重なることも多い。レイアウト的な見地からすると、こういう大きな段落部分は段末に配置するのが理想であるが、レイアウトの都合上、段の途中にせざるを得ないこともある。このとき、反復開始記号は小節線を兼ね、調号は反復開始記号の後に置かれるのが標準的な表記法だ。しかし、なぜかFinaleでは「小節線→調号→反復開始記号」の順になってしまう。しかも、Finaleはこれだけカスタマイズ性のあるソフトにもかかわらず、この表記がスタンダードなのだと言わんばかりに、この配置順に関するオプションなどは何も用意されていない。この問題は拍子変更とリピート開始が重なるケースでも同様に発生する。

　Finaleでこれを標準的な表記に改めるには、間にダミーの小節を挟んで、ダミー小節の冒頭でリピート開始、ダミー小節の直後で転調を行い、ダミー小節の全休符を非表示にした後、その小節幅を０にすることで実現するしかないのだが、このあたりについてはFinale User's Bibleに詳しく書かれているので、ここでは割愛する(要するに本を買ってくださいと言うこと......笑)。
　それでも、リンク・パートを作成しているとき、パートによっては転調部分が段末に来るものもあり、その場合は上記の方法を使っているとかえっておかしな表記になってしまう(下図参照)。つまり、リンク・パートでは、すべてのパートで転調部分を段の途中にするか段末にするかのどちらかに統一しない限り、両方の表記は同時には成立しないことになる。結局はパート譜を別ファイルに書き出す旧来の方法で個別に編集するしかない。

　じつは、この表記については、90年代の頃から幾度となくFinaleの開発元にメールで直談判したことがあるのだが、未だに無視され続けている。これだけ世界のデファクトスタンダードと謳われている楽譜ソフトがこの表記を堂々と続けているという事実を見せつけられると、なんだかこちらの主張の方が少数派なのではないかとさえ思えてくる。
　確かに、まだコンピュータ浄書が一般的になる以前のアメリカの出版楽譜の中にFinaleと同様の表記を見たことがあるので、アメリカではこの表記が主流なのかも知れないが、少なくとも、ヨーロッパの老舗出版社の楽譜にこんな表記を見たことはない(探せばあるのかも知れないが)。かつて訪問をしたことのあるドイツのヘンレ社などは、現在は多くの楽譜をFinaleで製作しているということだが、開発元にクレームを付けたりしないのだろうか？

１番括弧終了時の転調予告
　標準的な楽譜表記では、繰り返しで戻る際に現在の調と戻り先の調が異なる場合、一番括弧終了直前に転調予告を表記するきまりになっている。これは戻り先の拍子が異なる場合も同様である。だが、Finaleにはこの予告を表示させる機能はない。

　上記の譜例からもお分かりの通り、この転調にはいろいろなケースがあり、それぞれ異なる処理を行わなければならないのだが、いずれのケースもダミーの小節を利用して調号とリピートの位置を操作するという基本部分は前項と同じである。具体的な手順は同じくFinale User's Bibleに詳しく書かれているので、そちらをお読みいただきたい。
　この一連の作業は決して楽なものではない。しかも、リンク・パートにおいては、予告の位置によって表記が両立しないことも前項と同様である。
　Finaleには「演奏順序のチェック」というリピートを含む小節の順番を表示する機能が備わっている。それができるくらいなら、リピートの戻り先の調号や拍子を評価して、それを自動的に予告に反映させることは技術的に困難ではないはずだ。こんな面倒な作業からユーザーを解放してもらいたいものである。

　今回はFinaleの調号に関する不満点をまとめてみたわけだが、いずれのケースもこの表記によって演奏にただちに支障を来すようなものではないので(リピート時の調号の予告はあった方が演奏者にとっても親切だが)、演奏現場のみでFinaleを使っているユーザーにはさしたる問題ではないかも知れない。実際、私もレコーディングが差し迫っている状況でこれらの表記の修正に時間を費やしている余裕はないので、Finaleのデフォルト表記のままでレコーディングに臨むことは日常茶飯事である。しかし、出版楽譜製作に携わる者にとってはいずれも由々しき問題である。
　Finaleのこれまでのバージョンアップを見ると、特定のツールに関連する操作があるバージョンから一気にグレードアップされるということが定番になっている。もしかしたら、開発元は水面下でここで述べてきたようなことにも着々と対応を進めていて、あるバージョンで一挙に解決される可能性もある。それを大いに期待したいものである。

※ 11/10/20に記事追加

　Finaleがバージョンアップされる際には、それまでのバージョンが抱えていたおびただしい数のバグも修正されていることが多いのだが、一方で機能の強化や変更が思わぬバグを誘発させることもある。こういったバグはユーザーがある程度使い込んでから発見されることも多く、バージョンアップ後の比較的初期段階に見つかったものについてはマイナーアップデートで対応されることも多いが、対応しきれなかったバグについては次のバージョンに持ち越されることになる。
　現在Windows版は2011b、Mac版は2011cまでのアップデータが配布されているが、海の向こうの開発元は既に次期バージョン2012のベータテストを開始している時期であり、この時点でこれ以上の2011のアップデータが出る可能性は低い。現時点で確認されているバグについて以下に挙げておこう。

日本語歌詞が正しく割り付けられないバグ
　舶来ソフトの宿命とも言えるFinaleの日本語環境固有のトラブルは今日に始まったことではないが、今回もそんなバグが発生している。
　Finale 2011レビュー(1)でも既に触れたが、2011からリニューアルした歌詞編集ウィンドウ内に日本語歌詞を書いた場合、歌詞の途中から「クリックで割り付け」にて割り付けようとすると、カーソルを置いた文字とは異なる歌詞が割り付けられてしまう。このバグについては、日本語版がリリースされてから早期にユーザーからクレームが来たらしく、早速イーフロンティアのFAQにも報告されている。

　日本語ばかりの歌詞を入力している場合、実際にタイプされる文字は歌詞編集ウィンドウ内のカーソルを置いた文字より冒頭からおよそ2/3の位置の文字が割り付けられることに気付いた人もいるだろう。なぜこのようなことが起こるのか。
　日本語の部分は内部的には２バイトの文字コードで表現される。Finaleの歌詞ではひとつのシラブル(ひとつの音符に割り付けられる歌詞)に所属する文字は、通常日本語１文字＋区切り記号の半角スペースキャラクタの計２文字なのに対して、文字コードは３バイトが割り当てられることになる。もうお分かりかと思うが、Finaleは歌詞編集ウィンドウ内では文字数で勘定をしているのに、実際に割り付ける文字は文字コードのバイト数で勘定をしているのだ。上記の例では「さ」の冒頭からの文字数が21番目なのに対し、21番目の文字コードは「き」の次の半角スペースにあたり、そのシラブルに所属する「き」の文字が割り付けられたという按配である。これは、クリックを続けていくと、歌詞編集ウィンドウ内のハイライト部分が実際に割り付けられる文字とだんだんずれていくことからも分かる。その結果、上記の歌詞編集ウィンドウでは、スペースキャラクタを挟んだ２文字分がひとつのシラブルとしてハイライトされてしまっている。

　上の例では分かりやすくするために、ひとつのシラブルにつき１文字が対応するものとして説明をしたが、実際の歌詞では「しょう」などのように１つのシラブルに複数の文字が割り当てられたり、１バイト文字の欧文歌詞が混在することもあり、事情はもっと複雑である。それでもこの文字コードの仕組みを踏まえれば、正しい文字が割り付けられるよう歌詞編集ウィンドウ内でカーソルを置く位置を逆算で求めることも不可能ではないが、そもそも歌詞をタイプする度にそんな不毛な計算を強いられるのはナンセンスである。結局日本語歌詞を書く場合、イーフロンティアのFAQにも書かれているとおり、「クリックで割り付け」機能を使う場合は歌詞の先頭から順番に割り付けていくか、歌詞編集ウィンドウを使わずスコアに歌詞を直接タイプするしかない。
　文字数と文字バイト数が完全に一致する１バイト言語圏において、開発者がこの２バイト文字のことを全く考慮しなかったことは致し方ないところだが、こういうトラブルが起こる度に日本のユーザーは割を食うことになる。Finaleも、そろそろ言語環境に左右されないUnicodeへの対応に本格的に取り組んで欲しいものだ。

「符頭の変更」にて一部のキャラクタが変更できないバグ
　選択した範囲の特定の符頭を一括して変更するには、「ユーティリティ＞変更＞符頭の変更...」を使う方法が効率的だが、ここで「選択した符頭：」にスロット番号130以降のキャラクタを指定すると、変更されず無視されるか、または意図したものとは異なるキャラクタに変更されてしまう。符頭キャラクタは後半のスロット番号に多く含まれているので少々厄介である。

　代替策としては以下の２通りが考えられるが、いずれもユーティリティーにある符頭変更機能を完全に代用できるものではないことに留意する必要がある。

1. 「プラグインメニュー＞音符関係＞符頭の変更...」を使う方法。なお、こちらの方法では選択範囲の符頭を種類に関係なく一括して変更してしまうので、選択範囲の２分音符のみを変更したいといった用途には使えない。その場合は2.の方法を検討していただきたい。


2. 「道具箱ツール」の「符頭変更ツール」か「符頭微調整ツール」を使う方法。なお、こちらの方法では１小節単位での編集しかできないという制約がある。

　どうやら英語版ではこのバグは発生しないようなので、こちらも日本語環境が影響している可能性が高い。

　その他、2011以前よりずっと放置されたままのバグも結構残っている。さらに新たなバグが発見された場合はここで追加報告したい。

　Finale 2012で上記のバグはすべて解消された。メデタシメデタシ。

　仕事にかまけてレビューを怠っているうちに、今年は例年よりも早く日本語版がリリースされてしまったので、前回に引き続くレビュー第２弾は日本語版にて行うことにする。
　例年のことだが、Finaleの日本語版は英語版からのローカライズ作業を販売代理店のイーフロンティアが行う関係上、どうしても販売にタイムラグが生じてしまう。たいていの場合、日本語版が発売される前に本国ではバグフィックスや機能強化を施したアップデート版がリリースされるので、日本語版はいつもいきなりアップデート版からのリリースとなる。今回の2011では日本語版は2011aでのリリースとなったがイーフロンティアのFinaleのサイトには、早速Windows版は2011b、Mac版は2011cのアップデータが公開されている。

　さて、前置きはこれくらいにして、2011で大きく仕様が改善されたもうひとつの機能、五線のレイアウト機能について詳しく見ていこう。

直感的に編集可能になった五線レイアウト
　ある特定の組段の特定の五線間のみを広げようとしたら、曲中のすべての組段の同じ部分の五線が広がってしまったという経験は誰しも一度はあるだろう。これを意図通りに編集するには「組段の最適化」というコマンドを使う必要があるのだが、初心者にこの意味不明なコマンドの存在を気付かせることは容易ではない。2011では、このFinaleの解りにくいインターフェイスのひとつであった「組段の最適化」の呪縛からやっと開放された。
　2011のページ・レイアウトメニューにはもはや「組段の最適化」という項目はなく、すべての組段は最初から「組段の最適化を施した状態」であり、いきなり任意の五線を独立して上下に動かせるようになっている。これまでの「五線の個別編集を行うにはまず組段の最適化」という手順が染みついた人は一瞬面食らうかも知れないが、実際に操作してみれば、こんな当たり前のことがこれまでなぜできなかったんだろうと思えてくるはずだ。

　五線のレイアウト操作はとても解りやすく改善されている。
　これまでは組段中の特定の五線のハンドルを上下してもその五線のみが独立して動いていたが、2011からは選択した五線以下のすべての五線が追随して動くようになっている。これまで通り特定の五線の位置のみを変えたい場合はoptionキー(Windowsではctrlキー?)を押さえながらハンドルをクリックすればよい(隅々まで探してみたつもりだが、なぜかこの方法はマニュアルに記述がない)。また、特定の五線を曲全体で一括して編集したい場合は、ハンドルをダブルクリックして選択する。こうすることですべての組段のそのパートが選択状態になる。
　ところで、セットアップ・ウィザードやテンプレートから作成した場合、楽譜は最初から組段の最適化を施した状態であるわけだから、スクロール表示にて五線間隔の調整を行ってもページ表示では何も変化は起こらない。組段ごとの個別の五線の位置決めとは別にあらかじめデフォルトの全体の五線間隔を決めておきたいという場合は、上記のハンドルをダブルクリックすることで編集対象をファイル全体にする方法も可能だが、スクロール表示にて五線間隔を設定した後ページ表示に切り替え、「すべてを選択」状態にしたまま五線メニューの「五線の間隔...」を選択すると現れるダイアログにて「スクロール表示での間隔に設定」を選択する方法の方が簡単である。

　今回の仕様の大幅な変更に伴い、これまで可能だったドラッグによる五線の並び替えはできなくなった。実際に五線を動かしてみると、隣の五線を超えてドラッグできないことが分かるはずだ。五線の並び替えは、五線メニューの「五線の並び替え...」を選択すると現れるダイアログにて行う。ウィンドウ内に組段内のグループとグループ左横の三角印を倒すと現れる五線名を選択し、上下矢印ボタンで上下させるだけだ。

　ただし、自由な移動が可能なのはグループ内のみか、グループ化されていない五線のみであり、グループ内の五線をグループを越えて移動させることはできなくなっている。逆にグループ化されていない五線はどのグループにも入ることはできない。これを実現させるには一旦グループを解除するか、ひとつのグループにまとめる必要があるので注意が必要だ。

　五線メニューの「ドラッグ時に距離を表示」をオンにしておくと、ハンドルをクリックすると同時に組段中のすべての五線間隔が表示され、ドラッグに従ってその数値が変化する。一瞬、某ライバルソフトの機能を連想するが、数値による正確の位置決めを五線メニューにある「五線の特性」ダイアログを呼び出さなくても確認できるようになったことは大変ありがたい。

　その「五線の特性」ダイアログの操作性もかなり改善されている。
　これまでは最上段の五線からの距離で指定していたため、大編成スコアの下の方の五線ではあまりに大きな数値になりあまり意味をなさなかったのだが、2011からは直上の五線からの距離を指定する仕様に変わった。また、これまでは大編成スコアや五線の入れ替えで五線番号が非連続になっているスコアでは編集対象のパートと五線番号の関連が非常に解りにくかったのだが、2011からは五線番号ではなく五線名で指定するように変更された。さらには「プレビュー」ボタンの創設により、ダイアログを閉じることなく入力結果を楽譜に反映できるようになった。

　旧来の「組段の最適化」による空の五線を消す方法も、2011からはより直感的な操作に変更されている。組段内の空の五線を消したい場合は、組段すべての五線の左肩にあるハンドルをマーカーで囲んで選択し、コンテクストメニューから「空の五線を隠す」を選択するだけある。特定の五線のみを消したい場合は、消したい五線のハンドルをクリックして同様の操作を行う(下図)。また、曲全体で空の五線を消したい場合は、「すべてを選択」状態にして行えばよい。なお、五線を隠すことができるようにするには、「五線の属性」ダイアログボックスにて「未入力の五線を隠せるようにする」にチェックが付いている必要がある。

　隠された五線を再表示したい場合は、五線の左肩のすべてのハンドルを選択した状態で、コンテクストメニューから「空の五線を表示」を選択するだけである。また、組段内の特定の五線のみ再表示させたい場合は、隠された五線の位置にハンドルのみが表示されているので、そのハンドルのコンテクストメニューから「表示(楽器名)」を選択すればよい(下図)。

　改善された点もある。これまでは五線を隠した部分に後から音符を入力したり、隣接した組段の音符が入力された小節をその組段に移動させても、隠された五線はそのままだったのだが、2011からは自動的に表示されるようになっている。ただし、その五線を再び空の状態にしたからといって自動的に非表示なるわけではない。非表示にする行為はあくまで自発的に行うものである。

　このように、なかなか操作性の良くなった五線レイアウトの編集機能だが、それならそれで気になってくる部分もある。五線の垂直移動や表示/非表示は上下マージンの変動を伴う。ケースによっては組段のページへの追い込みや追い出しが発生し、その際、組段のレイアウトはかなり乱れてしまう。このあたりはレイアウト・ツールとの連係が必要になるわけだが、例えばマージンが変わってもつねにページ内の組段数を均等配置に保つ等、やり様はいくらでもあると思われる。今回は五線ツールの強化のみに絞り、そこまでは手が回らなかったというところだろうが、やや片手落ちの感が否めない。

新たなフォントが追加
　Finale 2011には、新たな３つのフォントが付属している。
　１つ目は、現代音楽などでよく使われる、打楽器の指示を記号で示したPercussion Font。

　２つめは、打楽器の多種のマレットを記号で示したMallets Font(一部上記のPercussion Fontと重複するキャラがある)。

　このフォントのキャラクタでは文字幅に工夫がしてあり、右手用の撥のキャラクタの直後に左手用の撥のキャラクタをタイプすると、交叉する撥を表現することができる。

　3つ目は初等音楽教育用と思われる、音符の中に音名や顔が描かれている符頭フォント。

　さしずめ日本なら音符の中に「ド、レ、ミ...」とか「イ、ロ、ハ...」とか書いてあるものが欲しいところだが、所詮は舶来のソフト、このあたりは望むべくもない。英語版がリリースされたとき、もしかして日本語版には日本販売代理店のイーフロンティアが独自に日本仕様のフォントを作ってバンドルしてくれるかもと密かに期待......なぞこれっぽっちもしていなかったが、やはりそのようなフォントはバンドルされず、英語版のものがそのまま付いてきた。

　使ってみて気になったのは、白抜き文字の部分や白玉音符ののバックの五線や加線が透けて見えてしまう点だ。通常、この手の楽譜の符頭ではバックの五線や加線は透けないようにするものだが、フォントで表現する限りこれは仕方ないのだろう(かつて存在したType 3形式のフォントは白抜き部分が透けないようにすることができたが、現在は廃れてしまった)。一応、符頭が線上に来たときに文字が潰れてしまわないように、「Ｂ、Ｅ、Ｆ」の中心の横棒がややセンターから外してデザインされているという工夫もみられるが、やはり読みづらいことには変わりない。
　仮に日本仕様のフォントを作ったところで上記の問題は同様に生じるわけで、認識性を備えつつ、かつ文字が五線や加線にかからないようにデザインすることは困難が予想される。日本仕様のフォントを作らなかったのは、もちろんイーフロンティアに開発する余裕が無かったことが最大の理由だろうが、ある意味正しい判断だったかも知れない。

新たなARIA Playerと、追加されたGarritanサウンド
　ARIA Playerはコントロール部分がミキサーライクになった最新盤のエンジンが搭載されている。

　ミキサーの各スロットに"SEND"ノブが取り付けられていることからもお分かりのように、ARIA Player単独で各パートのリバーブの深さを独立してコントロールできるようになっている。リバーブの設定は"EFFECT"タブをクリックすると表示される画面で行う。

　なお、ARIA Playerとは別に「インストゥルメントのセットアップ」画面の「マスター・エフェクト」でもリバーブをかけることができるが、両方を使うと二重にリバーブをかけることになるので注意が必要だ(もちろん意図して使うことも可能だが)。
　Garritanサウンドには、フルートセクション、金管セクション、バストロンボーン、児童コーラスAh、エレクトリックドラム、パッド系音色、スチールドラムの音色が追加された。
　ところで、ファイルを開いた直後にARIA Playerで音色を新たに呼び込んだ場合は問題ないのだが、ある程度編集を行ってから音色を呼び込んだ際にFinaleが強制終了してしまうことが多いのだが、我が家固有の問題だろうか？　

改善された点

曲の途中で楽器名やグループ名がフルネームで書けるようになった

　設定は簡単だ。フルネームにしたい部分の組段の最初の小節に対して、「小節の属性」ダイアログボックスにて、「五線/グループ名をフルネームで表示」というオプションをオンにするだけだ。ここをオンにすると、自動的に「段の先頭小節にする」もオンになり、その小節は強制的に段頭に配置される(そうでないとフルネームにする意味がないが)。

　これまでは、曲の途中に正式楽器名を書きたい場合は、省略楽器名部分に正式楽器名を記した楽譜スタイルを全パート分作り、冒頭小節に適用させる必要があったが、これからはそんな煩わしさからは解放される。
　ところで、この機能を設けたのであれば、コーダ切れとなったコーダ部冒頭のように、特定の組段のみ楽器名を非表示にするオプションがあっても良さそうなものだ。結局、コーダ部冒頭は未だに楽器名を非表示にする楽譜スタイルを作成してしのぐしかない(まあ、こちらは１つの楽譜スタイルですべてのパートを一括処理できるだけまだ救われるが)。

弱起小節に正しい音価の休符が自動的に表示されるようになった
　これまでは、Finaleの正規の方法で弱起を設定しても、弱起部分に音符か休符をこちらが入力しない限り、そこにはデフォルトの全休符が表示されていた。実際、弱起小節が全休符のまま作成された楽譜の曲頭でオーケストラが大混乱になったリハーサル現場を何度か見ている。これは楽譜作成者の不注意というより、むしろFinaleの設計ミスといえるもので、これまでずっと放置されてきたことの方が不思議なほどである。

　この弱起小節に自動的に入力される休符は、デフォルトの全休符と同じ扱いになっている。これまで、弱起小節に実際に正しく休符を入力していると、その五線は組段の最適化の対象にならなかった問題点もこれで解消された。

　とはいえ、これで弱起の休符の問題は全面的に解決というわけではない。なぜなら、弱起部分の休符は通常の休符と同様、最初の拍に左揃えに置かれなければならないのに、弱起小節全体の中央に置かれてしまうのだ。どうやら、これまで表示されていたデフォルトの全休符の位置のまま、それぞれの休符のキャラクタに変えただけのようだ。じつは、上記の楽譜でも厳密には弱起部分の休符は左揃えになっていない。これは楽譜表記としては明らかな誤りなので早急に改善を望みたい。

　Finaleの弱起は「空白時間の挿入」という旧弊な仕様により作成されている(「空白時間の挿入」の詳細にいてはFinaleのオンラインマニュアルをご覧いただきたい)。この方法で作成された弱起はイーフロンティアのFAQにも書かれているように、プレイバックにおいても問題を孕んでいる。結局、弱起についてはFinaleの正規の手順で作成せず、拍子記号ツールの「表示専用に別の拍子記号を使う」機能を使って表現するのが、現時点においても最も堅実な方法であることには変わりない。
　そもそも、１ファイル１曲を前提としていた開発黎明期ならともかく、ファイルの統合機能や、楽章ごとに楽器名をフルネームにできる機能等、明らかに１ファイル中に複数の曲が入ることを想定している今日、弱起が曲頭にしか設定できないという設計自体、根本的に見直す時期に来ているのではないだろうか。

「コーダ切れ」プラグインのバグが直った
　以前の記事でも紹介した「コーダ切れ」プラグインを使うとレイアウトが崩れてしまうバグがやっと直った。
　このバグ、旧式のPowerPC搭載Mac上やIntel MacでもRosettaモード(PowerPC互換モード)上では発生せず、Intel Macで使用したときのみに起こっていたバグなのだが、どうやらもともとIntelプロセッサを搭載しているWindows版では、ずっと以前からこのバグは発生していたらしい。つまり、Intelプロセッサ用にコード化したプログラム上で共通して発生するバグだったようだ。
　しかし、圧倒的に多くのユーザーを抱えているWindows版でこの問題が長らく放置されていたということは、このプラグインはほとんど使われていなかったのだろうか？　そもそもコーダ切れの作成を未だにプラグインに任せているということ自体、あちらではコーダ切れそのものが一般的ではないのかも知れない(実際、このプラグインの作成者はTGツールの作成者のドイツ人らしい)。

その他
　ファイルを開く際に、ファイル・メンテナンス(ファイル内の不要なデータのゴミ掃除)を自動的に行ってくれるオプションが追加されている。「書類メニュー＞データ・チェック」にある従来のメンテナンス機能もこれまで通り使えるが、実際にそちらを使ってみるとその処理速度に驚く。これまでは大きなファイルのメンテナンスを行うと処理状況がプログレスバーに表示されしばらく待たされていたのだが、2011からはプログレスバーは表示されず瞬時にメンテナンスが終了する。これだけメンテナンス作業が最適化されたからこそ、ファイルを開く際のメンテナンスが可能になったと言えるだろう。

　一方、2010で今回のファイル・メンテナンスのように大幅に処理が高速化されていたプラグインの「警告の臨時記号」は、なぜかプログレスバーの表示される2009以前の処理速度に戻ってしまった。これはちょっと残念。

　バージョンアップの度に少しずつではあるが確実に使い勝手をよくしているFinale。しかし、新たなバグも生じているようだ。こちらについては改めて報告することにしよう。

　８月下旬、音楽之友社よりFinale User's Bible 2008/2009/2010が発売された。前版2005/2006/2007の発売から３年ぶりの改訂版である。今回はこの本にまつわるエトセトラをお話ししよう(Fianle 2011のレビューの途中に割り込む形になってしまったが、一応これもFinale関連のタイムリーな出来事なのでお許しを)。

　　　　

なぜ2008/2009/2010なのか？
　Finale User's Bible(以下FUB)の初版は2003/2004/2005が対象、改訂２版は2005/2006/2007が対象とくれば、改訂３版は2007/2008/2009が対象となるのではないかと心待ちにしていた方もいたかも知れない。なぜ１年空けて2008/2009/2010となったのか？

　その話をする前に、改訂２版を刊行した際にあったちょっとしたエピソードを紹介しておこう。
　現在のところ、前版のFUB 2005/2006/2007のAmazonの紹介ページにこの本に対するレビューはないが、じつは、かつてこの本がリリースされてしばらく経った頃、星２つ(１つだったかも)の辛口レビューが掲載されていたことがあった。結局そのレビューは１ヶ月くらいの期間掲載されたのち削除されたわけだが、その内容を要約すると「新版が出たので買ってみたが、ほとんど内容は同じ。高い金を出して買って損した。初版を持っている人は買う必要ない」というものだった。このレビューを書いた人の憤懣も分からないでもないが、この人はちょっと勘違いをしている。
　ソフトウェアはバージョンアップ行うことで少しずつ機能強化を図ってゆくものであるが、それは枝葉末節な部分であり、根本的な操作体系というものは基本的には変わらないものだ(Finaleの場合はそれが足枷となってしまっている部分もあるが)。したがって、操作が変わらない部分については、バージョンがいくら上がろうが、それに関する記述を変えようがない。
　一方、Finaleは毎年バージョンアップを重ねているソフトであり、バージョンアップ時にソフトの操作が少しでも変わってしまえば、以前の操作手順を載せた本に技術書としての価値はなくなってしまうわけで、いくら大本に変更がなくても、その差分を更新した解説書はやはり必要になる。仮に操作に全く変更がなかったとしても、書名に対象バージョンを明記している限り、そのバージョンより新しいものが出た時点で、その本の旬は過ぎてしまう。日進月歩のコンピュータ関連の技術書が負う宿命といえる。
　辞典も数年おきに改訂版を出す。しかし、改訂されている部分は全体の一割にも満たないだろう。その辞典に対して「内容がほとんど同じじゃないか、けしからん！」と憤慨する人はまずいないだろう。この手の本はその一割に満たない改訂部分に価値があるのだ。おそらく上記のレビュワーが１ヶ月そこらで上げた拳を降ろしたのは、お門違いの自分の主張に気が付いたからだと思われるが(Amazonが不適切として削除するような過激な内容でもなかったし)、著者の一人としても何ともバツの悪い出来事ではあった。

　話を戻そう。
　改訂３版を出すにあたって、執筆者の間でも、2007/2008/2009として出すべきかどうか検討が行われた。
　まず１つ目の問題として、2008、2009の２度のバージョンアップでは、Q&A項目が劇的に変化するような機能の改訂は行われず、内容的に目玉となるような目新しい情報を盛り込めそうにないことが挙げられた。いくら一部分しか更新されないのが技術書の宿命とはいえ、やはり上記のAmazonのレビューのようなそしりは受けたくないものだ。
　そして２つ目の問題。Finale 2008からはブロック編集メニューが消滅し、そこにあった項目は編集メニューとユーティリティメニューに分散された。FUBでは、バージョンで操作が異なる部分はバージョンごとの説明が行われているのだが、この旧ブロック編集メニューがらみの編集はFUBの根幹を成すといえるほど広範囲に及び、2007と2008を両方扱った場合、記述は煩雑になり、紙幅もいたずらにかさんでしまう。
　じつは、FUBのページ数が初版本の419ページから改訂２版の564ページに一気に150ページ近くも増えたことに対して、出版社の方から、第３版はこれ以上ページ数を増やしてくれるなとのお達しが来ていた。確かに、改訂２版では初版より紙を若干薄くして対処したとはいえ、かなりのボリュームの本となっている。現実問題として、これ以上本を厚くすると使い勝手も悪くなるに違いない。
　結局、２つ目の問題が一番のネックになり、FUBを2007/2008/2009として出すことは見送られたのである。

　現在、FUB 2008/2009/2010のAmazonの紹介ページには、星５つの好意的なレビューが掲載されている。そのレビューは、私がここで釈明しようとしたことを見事に見透かして代弁しており、私自身、自分が提灯レビューを書いたと疑われまいかと案じたくらいである。いやはや、このレビューを投稿した人には恐れ入るばかりである。

新執筆陣
　FUBは、その前身である秋山公良氏が単独で著したFinale Bibleの流れを汲んでいる本であり、FUBの初版の際も秋山氏が中心になって企画立案＆執筆が進められた。しかし、その後秋山氏はFinaleのライバルソフトであるSibeliusの方にすっかり傾倒してしまい、最近は自分が教鞭を執る大学の授業でFinaleを使っている程度で、プライベートではほとんど使わなくなり、バージョンアップの度に改訂される新機能について行けなくなったという。「機能を把握していない者が執筆しても仕方がない」という理由で、自ら執筆陣からの離脱を申し出てしまった。
　FUBは私を中心に企画が進められることになり、これを機に新しい血を入れてみたくなった。そこで、執筆者の一人である黒川氏の紹介で、ネット上などでFinaleのサポートを精力的に行い、プレイバック方面にも明るい神尾立秋氏を新たに迎入れることにした。彼の担当した「トップノートの表示方法」などは、Finaleを知り尽くしていないと編み出せないじつにスマートな方法で、私も目から鱗だった(もし、私がそれを担当していれば、誰もが容易に思いつく陳腐な方法を紹介してしまうところだった)。FUBの大部分を担当している私と黒川氏は、どちらかというと浄書家視点で方法論を構築するきらいがあるのだが、神尾氏は我々とは異なる視点でFinaleと接しているのだろう、我々からすると思いがけない方法論を提示したりしてじつに興味深い。

　ところで、今回は私だけが「編著」となっている。私が中心となって原稿のとりまとめを行ったこともあるが、DTP作業も私一人で全部やってしまったことも理由のひとつだ。
　原稿のとりまとめについては、第２版の時も実質私が行っていたのだが、第２版までのDTP作業は秋山氏が行っている(奥付に制作協力としてAkiyama Music Designと記されている)。私もかつて音楽出版社の出版部で編集を行っていたことがあり、以前よりDTP作業はそれなりにこなしてはいたのだが、500ページを超える本丸々１冊を組んだのは初めてで、元来遅筆なことに加えて、目次や索引の作成などいろいろ不慣れなことも手伝って、結局当初予定していた５月の出版から大幅に遅れてしまった。
　それでも、自分で本を組むというのはいろいろメリットもある。FUBはとにかく譜例や図版をたくさん盛り込んでいるので、そのレイアウトは頭を悩す部分である。他人の原稿を組んでいると、最後の数行とか譜例だけがポツンと次のページに送り出されることもしばしば起こる。他人の原稿を勝手に削るわけにも行かないので、そんなときは、行間や文字間をうまく調整してページ内にうまく収めるわけだが、こと自分の原稿の場合は、うまく収まるように文章を削ったり、逆に白みが多いページは文章や図版を足したりといった調整が自在にできるのである。おかげで、今回の第３版は、文章がページをまたぐといった部分は最小限にとどめることができたと自負している。
　とはいえ、一般の人がFinaleを使ってそこそこうまく作った楽譜も、プロの浄書家が見れば、スペーシングや記号類の配置の甘さなどを指摘されるのと同様、私がInDesignのほぼデフォルト設定で組んだこの本など、組版のプロから見ればおそらくツッコミどころ満載であろう。このサイトなどを読んでみると、私ごとき組版の素人が本をレイアウトするなんぞ笑止千万という高笑いが聞こえてきそうである。
　「餅は餅屋に任せろ」という諺がある。この本のレイアウトもプロのDTPデザイナーに任せるという選択肢もあったのだが、結論から言うと、そうした場合、編集は複雑になり、出版はさらに数ヶ月遅れていただろう。痛し痒しである。

なぜFUBの図版はほとんどMac版なのか？
　じつは、これは出版元の音楽之友社の編集者から訊かれた質問である。これに対して「読者からクレームでも来ているのか？」と逆に尋ねたところ、「そういうクレームは一切来ていない」とのこと。しかし、クレームとはいかないまでも、Windowsユーザーからすればちょっと気になることかも知れない。

　理由は大したことではない。執筆者がみんなMacユーザーだからである。もしWindows環境を持たない私がFinaleのWindows版のキャプチャを撮ろうとすれば、Windowsユーザーの誰かに頼まなければならない。その際、ダイアログの数値や設定もこちらの指定通りに再現してもらわなければならない労力を考えると、FUBの膨大な図版のキャプチャを他人に頼むなどということは、人間関係の崩壊にもつながりかねない由々しき問題であることがお分かりいただけるだろう。
　それと、Windowsユーザーの方には申し訳ないが、同じダイアログのキャプチャを並べてみれば、最新のWindows 7であっても、残念ながらその美しさはMac OS Xのそれには到底及ばない。美しい楽譜を追求しようとする本であるからには、そこに使われる図版もすべからく美しくあるべきである。
　さらにもうひとつ。世の中のFinaleのWindows版とMac版のシェア争いでは圧倒的にWindowsに軍配が上がる。実際、Finaleに関する解説本の多くにはWindows版の図版が使われている。一方、楽譜浄書の現場では、DTPとの連系の良さという理由から圧倒的にMacが使用されている。FUBは作編曲家だけではなく、プロの浄書家にも携えてもらいたい本であり、そういう意味でも、一般の解説本とは異なるスタンスでありたいと考えているのだ。

　まあ、後半になるほどじつはどうでもいい理由なのだが(笑)、あえて理由を挙げるとすればそんなところだろうか。
　じつはFUBでは、Windows版とMac版で操作が異なる場合は、Windows→Macの順に説明を行う決まりになっていて、一応Windowsユーザーに配慮がなされている(配慮といえるほどのものでもないが)。

第４版はいつ出る？
　先のことはそのときになってみなけりゃ分からないというのが私の持論だが、まあ実際のところ、これもFinale 2012の内容次第である。もし、2012がメジャーバージョンアップで操作に大幅な変更があれば、当然2010/2011/2012対象として出すべきだろうが、マイナーバージョンアップに終われば、今回と同様、１年見送る可能性もありえる。
　第４版を出すとすれば、内容的にも何か違う視点を盛り込みたいとも思うのだが、ページ数の制約もあり、今のところまったく白紙である。やはり、そのときになってみなけりゃ分からない(笑)。
　一方、電子書籍も一般化しつつあるこのご時世、紙媒体でのリリースがベストなのかどうかもそろそろ考える時期に来ているかもしれない。２、３年後はまだしも、10年後のこの手の技術書は、差分を頻繁に更新でき、PDA端末等に映し出されるデジタル媒体になっている可能性は非常に高い(そんなことよりFinale 2020は存在しているのか？)。
　「楽譜を紙に印刷して使う」というアナログな光景はしばらく続きそうだが、それもそのうち電子譜面台に映し出されるようになるのかも知れない。そもそも、パソコンで楽譜を作るという概念自体、もっと違うものになっている可能性が高いのだから。

※ 11/3/22、11/4/20に記事追加

　海の向こうでは例年通りFinale 2011がリリースされた。早速紹介してみよう。

　これまでのFinaleは、インストールを行うとアプリケーションフォルダ内に"Finale 20xx"というフォルダを作り、その中にアプリケーションを始め、プラグインやライブラリ等の各種ファイルが入っていた。私のようなヘビーユーザーは、Finaleをインストールすると、まず最初に自分用の楽譜書式ファイルやフォント定義ファイル等のカスタマイズを行うわけだが、Finale 2011をインストールしてまず面食らうのは、アプリケーションフォルダには"Finale 2011"アプリケーション単体しかないことだ。プラグインやライブラリはいったいどこに？
　これらのファイルは、Macの場合「<ユーザ名>/ライブラリ/Application Support/MakeMusic/Finale 2011」フォルダに移動している(Windows 7/Vistaでは「Users/<ユーザ名>/AppData/Roaming/MakeMusic/Finale 2011 」フォルダ)。2011からは、設定ファイルをユーザーフォルダ下に個別に管理することで、１台のマシンを複数ユーザーで利用する場合に対応したものだ。

　Finale 2011を使用してまず気付くのは、楽譜の各アイテムのカラーリングだろう。これまでのバージョンではビビッドなカラーが使われていたのだが、2011からは楽譜アイテム部分は黒みがかった彩度を押さえた色に変更されている。インターフェイスカラーはこれまで通りビビッド系の色調のままなので、楽譜要素とそれ以外の要素を明確に区別させようとする意図が伺える。

　もちろん、このカラーリングはカスタマイズできるので、従来のカラーリングに戻すことも可能である。
　また、レイアウト関連のアイコンがピクトグラム的なイメージに変更された。

　余談だが、少なくともMacを使っている限り、最近はアンチエイリアス処理のされていないジャギーむき出しの白黒二値図版をお目にかかることはほとんどなくなったが、Finaleの場合、未だにダイアログのあちこちにそういう図版が残っていて、そこだけ時代に取り残されているような感じがする。どうでもいいようなことかもしれないが、クリエイティブな仕事をしている者にとっては、やはりこういう部分は気になるものだ。

　ここのところ、バージョンアップのたびに特定のツールもしくは機能に焦点を絞って大幅な機能改善を図るというパターンが定着してきたFinaleだが、今回のそれは歌詞ツールとレイアウトツールの２点に絞られている。Finale 2011レビュー第１回目は、まずこの歌詞ツールがどう強化されたのかを詳しく検証してみよう。

強化された歌詞ツール
　まず、歌詞のスペーシングが改善された。これまでは小節の１拍目に長い単語があると、小節線と１拍目との間に不必要なスペースが取られていたのだが、これが解消された。

　また、これまではパッセージの最初にハイフンや音引き線を伴う単語があると、やはり次の音符との間に不必要なスペースが取られていたのだが、これも解消された。これらは90年代から幾度となく開発元に改善を申し出ていた項目なのだが、やっと改善されたという感じである。

　ただ、今回の改善でFinaleの歌詞のスペーシングが完璧になったわけではない。次の譜例の場合、歌詞のスペーシングは各段で独立していなければならないはずだが、これについては未だに互いの段の影響を受けている。

　今回の歌詞の処理でユニークなのは、「ファイル別オプション - 歌詞」であらかじめ指定した約物を、文字の位置合わせの対象から外すことが可能になった点だ。

　残念なことに、やはり舶来ソフトの悲しさか、日本語の２バイトの約物については、入力欄に入力してもエラーとなって受け付けてくれない。ただ、英語版の場合は「ファイル情報」などの入力欄でも２バイト文字を受け付けてくれないが、日本語版ではエラーにならないので、この約物処理についても日本語版に期待をしたいところである。とはいえ、あちらの開発者が２バイトの約物に対応したプログラムを組んでいるとは考えにくく、仮に２バイト文字の入力を受け付けたとしても、正常に機能することは望むべくもないが......。

※ 11/3/22追記：
　日本語版ではちゃんと対応されていた。素晴らしい！

　ネガティブな話になってきたので、気を取り直してレビューを進めよう。
　2011からは、歌詞入力のインターフェイスも変更されている。特に歌詞編集ウィンドウが改良され、このウィンドウは、楽譜に直接歌詞をタイプしている際にもフローティングパレットのように常時表示させることができ、楽譜に直接タイプする歌詞内容が歌詞編集ウィンドウ内にもリアルタイムに反映される。また、歌詞編集機能のほとんどがウィンドウ内のボタンから呼び出すことができるようになっている。

　ただ、「クリックで割り付け」を選択した場合、歌詞入力を任意の場所から再開したいときに、これまでは再開したい音節を「クリックで割り付けダイアログボックス」ウィンドウ内でスクロールして左端に持っていくことで指定できていたのだが、2011からは「クリックで割り付けダイアログボックス」は廃止されたようで、マニュアルを読んでみてもその指定方法がよく分からない。これについてはもう少し研究してみたい。

※ 11/4/30追記：
　これについてはこちらをお読みいただきたい。

　2011からは、歌詞ツール選択中は歌詞メニューの横に"Text(文字)"メニューがつねに表示され、楽譜に直接タイプしている際にも、フォントの切り替えが容易にできるようになっている。この文字メニューは、テキストツールなどで使う通常の文字メニューとは異なり、「ベースライン調整」や「文字間調整」などの機能が大幅に省かれたシンプルなものになっている。
　余談だが、日本語歌詞で１つのシラブルに「しょう」などとタイプした場合、プロポーショナルな文字幅を持っているMS P明朝などの一部のフォントでもない限り、文字間の開きが目立つので、それを文字間調整機能を使って詰めたいところだ。

　過去のバージョンでは、歌詞編集ウィンドウを開いている際にのみ現れる文字メニューにも「文字間調整」等の項目があったのだが、実際には数値を設定しても歌詞にはまったく機能しなかった。機能しない項目をアクティブにしておいても無意味ということからか、2004あたりからは、これらの項目がグレー表示(使用不可能)になり、2011ではついに項目そのものがなくなってしまった。これは、歌詞に文字間調整等の機能はもはや不要という開発者の意思の表れであり、これで歌詞の文字間調整の可能性は完全に潰えてしまったと言えよう。世界地図の東の端の国で使われているカナなどという文字の文字詰めの事情など、本家の開発者にとっては知るよしもないことだろうが、残念なことだ。

　またまたネガティブな話になってしまったので閑話休題、その歌詞専用文字メニューの中に、"Insert Hard Space"と"Insert Hard Hyphen"という新たな項目がある。

　Finaleではスペースとハイフンはシラブルの区切り記号として扱われるので、１つのシラブル中にこれらのキャラクタを含ませることはできない。どうしても含ませなければならない場合は、代用スペースまたは代用ハイフンを入力するしかないのだが、特に代用ハイフンは正規のハイフンより明らかにデザイン的に長いので、これらが混在すると不自然な印象はぬぐえない。

　私はこのメニュー項目を見たとき、このコマンドを使えば、文字列に特殊な制御を施してシラブル中にも通常のスペースやハイフンを入れることができるようになったのかなと密かに期待したのだが、実際に試してみると、従来の代用キャラクタを挿入するだけの機能ということが判り、その期待はもろくも崩れ去ってしまった。それでも、これらの代用キャラクタの入力にaltキー＋4桁の数字を入力しなければならなかったWindowsユーザーにとっては、その煩わしさから解放されるだけでも福音といえるかも知れないが。
　ところで、歌詞に日本語フォントを使っている場合、この代用スペース、代用ハイフンは、それぞれ半角カタカナの「ﾊ」、「ﾐ」と表示されてしまうので注意が必要だ。これを回避するには、欧文部分は欧文フォントを使うか、代用キャラクタのみを欧文フォントに変更するか、いずれかの方法で対応する必要がある。

　最後にもうひとつ、新機能を紹介しよう。
　これまでは発想記号等で書くしかなかった歌詞番号が、歌詞の機能としてサポートされた。使い方は極めてシンプル。歌詞メニューから"Auto-Number"を選択し、そのサブメニューから「バース」「コーラス」「セクション」それぞれの項目にチェックを付けるだけだ。すると、それぞれの歌詞の先頭部分に自動的に歌詞番号が付加される。

　なお、この歌詞番号は個々の歌詞のライン(歌詞編集ウィンドウ内に表示される連続した歌詞)の冒頭にしか付加されないこと、「バース」「コーラス」「セクション」単位で全部付けるか全く付けないかの二者択一であり、個別にオンオフはできないこと、位置の移動等の編集は全くできない等の仕様のため、繰り返しがあったり、合唱などでそれぞれの声部が個別の動きをする場合など複雑な構造を持つ歌詞の場合には運用に注意する必要がある。
　例えば、２番の歌詞が１番のラインの続きから始まる場合は、この機能は使えない。

　また、歌詞の共通部分を別のラインを使用してまとめている場合、そのラインを同じバース内で書いていると、冒頭部分にそのラインの歌詞番号も表示されてしまう。

　上記のケースでは、「テュリャ......」のラインはパースを使わず、コーラスかセクションを使い、そちらの歌詞番号をオフにする必要がある(このあたりのノウハウは次回のFinale User's Bibleの恰好のネタになりそうだ)。

　次回は、もうひとつの大改訂であるレイアウトツールを中心にレビューを行ってみようと思う。

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

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

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

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

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

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

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

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

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

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

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







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







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

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

　前回はパーカッションの扱いとコードネーム機能に絞ったレビューを行ったので、今回はそれ以外の新機能についてレビューしてみよう。

リハーサルマークの改善
　リハーサルマークの並びが自動化された。発想記号のリハーサルマークカテゴリの設定において、リハーサルマークの並び方を定義しておくと、ひとつのリハーサルマークの設定だけで曲中のすべてのリハーサルマークをコントロールできる。

　たとえば、ABC順に並ぶリハーサルマークを定義する。それを楽譜中に最初に配置すると、まず[A]が置かれる。そのマークより後の小節に新たなマークを置けばそれは自動的に[B]になる。逆に前の小節に置くと、新たに置かれたマークが[A]になり、最初に置いたマークは自動的に[B]に並び替えられる。すなわち、楽譜中にリハーサルマークをランダムに配置していっても、つねに自動的に並び替えられてゆくのだ。これで、うっかり同じ番号を振っていたり、番号を飛ばしてしまったりするミスはなくなるし、何より、作編曲中にリハーサルナンバーの番号を意識しなくてもすむのは精神衛生的にもすこぶるよろしい。

　また、組曲や多楽章形式の曲など、一つのファイルに複数の曲が入っている場合、新たな曲が始まるたびにリハーサルマークの属性をリセットすれば、その位置から振り直してくれる。

　当然のことながら、古い慣習で[Ｉ]や[Ｏ]を飛ばしたり、ダッシュを含むような不規則なリハーサルマークはシーケンスとしては定義できないので、従来通り単独で置くしかない。
　また、日本語版に付属するRentaroフォントを使ってリハーサルマークを定義する場合、[Ｚ]を超えて[AA]となったときには正しく表記されなくなるので注意が必要である。

　小節番号をリハーサルマークとして利用することも可能である(上記の発想記号の設計ダイアログ中のポップアップメニュー参照)。小節番号機能で振られた小節番号とダブった箇所は、小節番号の方を自動的に非表示にするオプションも用意されている。

スコア譜とパート譜で独立した設定が可能になった小節番号
　2010からは、ひとつの小節番号定義に対して、スコア譜とパート譜の表示方法を独立して設定できるようになった。

　吹奏楽譜などでは、パート譜では各組段の冒頭のみに、スコア譜では小節ごとに小節番号が振られることが多い。従来のFinaleでこれを実現させるには、リンクパートを設定したスコア譜から最終的にスコア譜のみを抜き出して、小節番号を新たに定義し直すしか方法がなかったが、2010からはひとつのファイルでこれが実現できる。

プレイバック音源にエフェクターが利用可能
　プレイバック音源ごとに独立したVST/AU経由のプラグインエフェクターをかけることが可能になった。また、音源同士の音量バランスも調整可能になっている。

透明化されたハンドル
　これまではただの四角だったハンドルが透明になり、選択状態のハンドルには色が付くようになった(色は初期設定で変更可能)。これで、楽譜を縮小表示にしているときなどに、記号類がハンドルに隠れてしまうことは防げる。

　一方、上記の画面をご覧いただければお分かりのように、透明化されたことによってコントラストは落ちてしまうので、認識性という意味ではやや弱くなってしまった感もある。さらに、ハンドルがちょうど符頭などの黒い部分と重なってしまうと、全く見えなくなってしまうという欠点もある。

　やっぱり従来のハンドルの方がいいという場合は、プログラムオプションの設定で元に戻すこともできる。かくいう私も、最初は物珍しさも手伝って透明ハンドルにしていたのだが、結局、従来のハンドルに戻してしまった。このあたりは好みの問題だろう。

新しい音楽記号フォントが付属
　ブロードウェイの写譜屋の筆致を再現する音楽記号フォントが新たにバンドルされた。通常の記譜用フォントとパーカッション符頭用フォント、テキストフォントの３種類のフォントで１セットになっている。Jazzフォントほど手書き風に崩れておらず、写譜ペンで丁寧に清書した楽譜というイメージである。

ハイパーリンクの埋め込み
　テキストブロックにURLやメールアドレスを埋め込めるようになった。リンクが埋め込まれた部分は青字に変わり、下線が付く。

　楽譜にハイパーリンク機能が必要かどうかは議論の分かれるところかも知れないが、埋め込まれたリンクはFinale Reader等で閲覧する際にも有効なので、自作曲のFinaleファイルを他人に渡したりFinale Showcaseに投稿した際に、作曲者名の部分に自分のアドレスを仕込んでおくなどという利用法も考えられる。ちなみに、PDFとして書き出した場合は、リンクは無効になってしまった(そこまで自動化してくれれば文句ないのだが......高望みか)。

　ざっと、2010の新機能を紹介してきたが、気になるバグについての情報も記しておこう。
　2010はまだ試運転を始めたばかりだが、それでも早速いくつかの新たなバグを見つけてしまった。「Finale 2010レビュー(1)」のコードネームの項で紹介しているバグの他にも、道具箱ツールの操作時にメッセージバーに表示されるはずの数値が表示されないバグ(マニュアルには表示される旨が書かれている)も確認されている。使い込んでいくと、さらに新たなバグが見つかる可能性もありそうだ。
　既存のバグについてはどうだろうか。「コーダ切れの作成」プラグインのバグに至っては、直るどころか、後半の組段の符尾や付点が消えてしまうというオマケ付きだ。これでは使い物にならない。

　ライブコピーされた小節やその直前の小節に特定の項目のみ(変形図形等)をコピーすると、その小節の内容が消えてしまうバグ(2009から発生)もそのままだ。
　なお、「後打音をコピーすると前打音になる!?」で紹介したバグは、今回のバージョンで修正されていることが確認された。

　人間とは現金なモノで、あるものを手に入れると、さらにもっと上を手に入れたくなるものである。Finaleの機能においてもそれは例外ではない。
　たとえば、今回、小節番号でスコア譜とパート譜で別々の表示が実現できるのなら、それを発想記号でも実現してもらいたいと思うのは高望みだろうか？　１ファイル中に複数の曲を入れることを想定して練習番号を曲ごとにリセットできるなら、曲ごとに冒頭のパート名をフルネームで表示させることができてもいいはずだ。テキストブロックやコードネーム、歌詞は直接スコア上で編集できるのに、なぜ発想記号だけ未だにエディタ上でしか編集できないのか。逆に、発想記号のマクロ定義はリスト上で直接指定できるのに、他のマクロ定義はいちいち楽譜に戻らなければいけないのか......等々、現状に対する不満や要望は枚挙にいとまがない。
　現在FinaleにはSibeliusという強力な競合ソフトがあり、ここ数年の両者のバージョンアップは互いを非常に意識したものになっている。たとえば、今回のリハーサルナンバーの自動化機能はSibeliusでは初期バージョンから実現していた機能である。一方、最近新バージョンをリリースしたSibeliusには、Finaleの既存機能であるマイク採譜やタップテンポ機能が盛り込まれた。こうしたことはライバルソフト同士の宿命と言えるが、もし、Finaleにライバルソフトがなく、楽譜作成ソフトのシェアを独占していたら、Finaleの開発元は現状に満足してしまい、機能向上のための開発は停滞していただろう。MakeMusic社が開設しているユーザーフォーラムには、Sibeliusを引き合いに出してスタッフに機能強化を求めるユーザーの声も少なくない。強力なライバルソフトがあるからこそ、ソフトは切磋琢磨されてより良いものへと進化して行くのである。
　私の知り合いは古参のFinaleユーザーだったが、Sibeliusの魅力に取り憑かれてしまい、とうとう宗旨替えをしてしまった。私は仕事との相性もあって今後もFinaleを使い続けることになるだろうが、Finaleの向上のためにも是非ともSibelius陣営にも頑張ってもらいたい。そして、それにも増してそのSibeliusを凌駕せんと日々奮闘するFinaleの開発スタッフにエールを送り続けたいものである。

　例年ならアメリカ本国でのFinaleの新バージョンのリリースは７月に入ってからなのだが、今年は約１ヶ月早くFinale 2010がリリースされた。現物が手に入ったので、さっそくレビューを行ってみよう。

　起動画面は極めてシンプル。
　余談だが、前バージョンFinale 2009の起動画面は、パッケージと同様、ヒップホップ風の黒人男性がサックスを持っている絵だった(2009のレビューを参照)。ところが、未だに黒人に偏見を持っている人がいるらしく、日本語版の販売を行っているイーフロンティアのお客様窓口に「なぜ起動のたびに黒人を拝まなきゃならんのだ！」というクレームを寄せた人がいるらしい。かつて、日本語版のパッケージは独自のデザインにしていた時期もあったが(起動画面が北斎の赤富士だったり)、現在は開発元のMakeMusic社の意向で全世界共通のデザインになっているのだという。そんな事情はクレーマーにとってはあずかり知らぬことだろうが、イーフロンティアの窓口担当者もさぞや閉口したことだろう。
　そんなことが今回の起動画面のシンプルさに関連しているかどうかは分からない。アバウト画面では、これまでと同様、パッケージと同じトランペットを吹いている白人女性が表示されている。

　さて、毎度のことではあるが、マニュアルのWhat's Newの部分には2010で新しくなった機能の紹介がある。この項目の概略を以下に挙げてみる。

• 簡単になったパーカッション入力
• リニューアルされたPercussion Layout(旧パーカッション・マップ)
• プレイバック音源との対応を定義するPercussion MIDI Map
• 拍に所属するようになったコードネーム
• コードのプレイバックの向上
• コード入力の向上
• コードネームのサイズを調整可能
• 自動制御されるリハーサルマーク
• スコアとパート譜で独立した小節番号が設定可能
• 省略の記譜法の強化
• Music Education Worksheets(音楽課題テンプレート集)が付属
• 拡張されたグラフィックスの扱い
• Broadway Copyistフォントの付属
• オーディオとプレイバックの強化(VST/AUエフェクトプラグインが利用可能)
• 歌詞の書き出し機能
• スキャン機能の向上
• ヘルプ機能の強化
• 透明になったハンドル
• テキストブロックへのハイパーリンク埋め込み

　ここ数年のFinaleのバージョンアップでは、特定の項目に絞って大幅な機能改善を行うというパターンが定着してきた。今回のバージョンでの大きな改変は、パーカッションとコードネームの２点に絞られると言えよう。まず、第１回目はこの２点についてレビューを行ってみることにする。

扱いやすくなったパーカッション
　これまでは、パーカッションマップで定義された五線への音符の入力は、MIDIキーボードを使わない場合、お世辞にも使いやすいとはいえなかった。たとえば、ドラム譜においては、ハイハットのクローズとオープンは楽譜上では同じ位置に同じ符頭で書き表されるが、クローズとオープンの切り替えは面倒な上に、見た目の区別が付かないため、現在どちらに切り替わっているのかはプレイバックして確認するしかなかった。
　2010からは、これから入力しようとしている楽器が何なのか、つねにナビゲーションで表示されるようになった。ステップ入力でのハイハットクローズ、オープンの切り替えは簡単だ。音符カーソルを上第１間に置き、カーソルを上第１間の範囲で上下させると楽器が切り替わる。慣れてくれば、微妙なマウスのコントロールだけでクローズとオープンの混在したリズムもスイスイ入力できるようになるはずだ。

　高速ステップ入力では、編集枠のカーソルの位置に従って楽器名が表示される(符尾が上下に分かれている場合は音符と重なってやや読みにくいが)。また、これまでは、入力された音符や休符を上下にドラッグして変更しようと思っても、とんでもない位置に飛んだりして思い通りに動かすことが困難だったが、2010からはこれらの編集もスムーズに行えるようになっている。

　Finaleは、2009からプレイバックに任意のソフト音源を使えるようになったが、Finale付属のマーチング・パーカッション専用音源をはじめ、エスニック系のパーカッション音源のように、パーカッションの楽器配列が従来のGMのものとは全く異なる独自の配列になっているものも多い。これまでは、各打楽器に対して実際に鳴らすMIDIノート番号と楽譜上の音符の配置の関連付けを「パーカッション・マップ作成」ダイアログ内で一括して行っていたのだが、多種多様になった打楽器とMIDIノート番号との関連付けは、2010からは独立したPercussion MIDI Map Editorで行うようになった。そして、旧来の「パーカッション・マップ作成」ダイアログはPercussion Layout Designerと名称が変わり、ここでは、Percussion MIDI Map Editorで設定した各打楽器の楽譜上での配置方法を定義するのみになっている。これに伴い、2010からは「パーカッション・マップ」という名称はすべて「Percussion Layout」という名称に改められている(一部のプラグインやマニュアルにまだ"Percussion Map"という表記が残ってはいるが)。

　さて、上記の画面をご覧いただけるとお気付きだと思うが、扱える符頭が全音符、倍全音符まで拡大されている。これで、「パーカッション・マップは全音符がお嫌い!?」の記事で憂慮した、全音符が２分音符の符頭で代用されているような妙ちくりんで嘆かわしい楽譜は根絶されるだろう。

　上で作成した和太鼓セットでは４つの楽器しか使われていない。MIDIキーボードを使わない入力では、定義された楽器しかナビゲーションに現れないので問題ないが、MIDIキーボードを使った入力で定義外のMIDIノートを入力してしまったり、コンバートしたMIDIデータに定義外のMIDIノートが含まれていた場合は、その音はオレンジ色の符頭で警告表示される(印刷は可能)。

　今回の仕様変更で、パーカッションはかなり扱いやすくなったとはいえ、各打楽器のMIDIとの関連付けの部分はまだまだ初心者には敷居が高いと思われる。しかし、新規入力の際、セットアップ・ウィザードを利用すれば、Finaleが自動的に適切なPercussion Layoutを設定してくれるので、通常の使用をしている限り、Percussion MIDI Map EditorやPercussion Layout Designerをユーザーが意識する必要はほとんど無いと言えよう。

仕様変更されたコードネーム
　コード入力は、これまでは主に「手動入力」(コード定義ダイアログ経由)、「楽譜へ直接タイプ」「MIDI入力」のどれかから選択する方法だったが、2010からは、メニューからモードを切り替えることなく、「楽譜へ直接タイプ」と「MIDI入力」が併用でき、必要に応じてコンテクストメニューからコード定義ダイアログを呼び出して編集するというインターフェイスになっている。

　2010から大きく変わった点は、これまで音符(休符)に所属していたコードネームが、五線(正確には拍)に所属するようになったことだ。これで、これまでは裏ワザを使わなければ実現できなかった全休符小節や全音符等の拍点のない部分へのコード付けも容易になった。したがって、コードネームの下の音符を消去したり、まったく別のリズムに変更しても、コードネームが消えることはない。

　また、コードネームの所属を後から自由に変更することもできるようになった。このあたりの操作は、2009からの発想記号と同様である。

　さらに、コードネームの拡大縮小率をファイル全体、または個別に変更できるようになった。これは著しく小さい、もしくは大きな五線に付くコードネームの大きさにバイアスをかけたい場合には有効である。ただし、ひとつのコードサフィックス中の個々のキャラクタの絶対位置は100%の時と変わらないので、拡大縮小率を大きく変えるとバランスが崩れてしまう。せいぜい90%〜110%の間にとどめておくのが無難だろう。

　この機能を聞いたとき、サフックス全体が相対的に拡大縮小するものだと期待していたのだが、ちょっと肩すかしを食らってしまった感がある。これは改善を望みたいところである。

　このようにいろいろ仕様変更されたコードネームだが、早速いくつかの問題点も発見した。
　コードネームが音符に所属しなくなったという仕様変更のせいで、旧バージョンで可能だった、特定のレイヤーのコードネームのみを非表示にする楽譜スタイルは機能しなくなる。具体的には、旧バージョンの「スラッシュ表記」や「リズム表記」においては、レイヤー１以外のレイヤーに付けられていたコードネームは非表示になるが、そのファイルを2010で開くと、隠れていたコードネームもすべて表示されるようになる。これは仕様の変更によるものであるから仕方ないことだが、この旧バージョンのギミックを使っているファイルを開く場合は注意が必要である。

　もうひとつ、スペーシングオプションで「衝突を避ける項目」にコードネームを指定していても、音符のない部分に付けられたコードネームはスペーシングの対象にならないようで、状況によってはコードネームの衝突が生じてしまう。これを避けるには、結局スペーシングの対象にするためのダミーの音符(休符)を裏レイヤーに入れる必要があり、これでは以前の状況と大して変わらない。このあたりは、次のアップデートで改善されることを期待する。

　また、ユーティリティーメニューのコード定義変更を行う際、小節の一部を選択していても、変更がその小節全体に及んでしまうようだ。まさか、今回のコードネームの仕様変更に伴う仕様変更ということはないだろうが、早急にバグフィックスしてもらいたいものだ。

　楽譜はひとつの項目が他の項目と寄せ木細工のように絡み合う。したがって、大きな仕様変更を行った際は、その影響が思わぬところに出ることがある。今年は例年より１ヶ月早いリリースだったが、出荷を急ぐあまり、そのあたりの検証がおろそかになっていたのではないだろうか。

　次回は、それ以外の機能についてレビューしてみよう。