バグ情報 の最近のブログ記事

　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以前よりずっと放置されたままのバグも結構残っている。さらに新たなバグが発見された場合はここで追加報告したい。

---

11/10/20に追記

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

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

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

　たとえば、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離れを起こさせたのはあのブログのせいだ！」などと後ろ指を指される事態はぜひとも避けたいので、たまにはポジティブな話題......「Finaleの知っておくとお得情報」をTIPSカテゴリで提供していこうと思う。

　その第１弾はダイエットの話である。ダイエットの話といっても、すっかりメタボオヤジと化した私の健康管理の話をするわけではなく(そんな話をしたところで誰も聞いてはくれないし)、Finaleファイルのダイエットの話である

　Finaleで楽譜を書いていると、次第に独自に作った発想記号や変形図形などが増えてゆく。また、定型のレイアウトやフォントセットなども決まってくるだろう。Finaleではこれらをライブラリとして保存し、新規ファイルにそのライブラリを読み込むことで自分独自の資産を受け継ぐことができるのだが、この方法ではマクロキーまでは覚えてくれず、ライブラリを読み込む度にマクロキーを再定義しなければならないのが欠点だ。この再定義の作業がイヤなら、これらの仕込みを済ませたものをデフォルトファイルとして使用する方法もある。しかし、そこからさらに新たな発想記号や変形図形を作れば、そのデフォルトファイルにも仕込み直さなければならないという煩わしさがある。
　じつはもっと良い方法がある。完成したファイルを複製し、その楽譜内容を一旦全部消去した状態から新たな曲を入力するのである。一見前時代的でナンセンスな方法に見えるが、これが一番簡単で確実な方法である。私はこの方法を家に代々伝わる糠床(最近、糠床は絶滅危惧種だが)になぞらえて「糠床方式」と呼んでいる(人口にはまったく膾炙していない)。ちなみに、私の回りの同業者にも訊いてみたところ、やはり結構な人がこの糠床方式を使っていた。

　さて、この「糠床方式」で受け継いだファイル、実際の音符の情報に比べてファイル容量がやけに膨れあがっていると感じたことはないだろうか？　じつは、Finaleは楽譜上の音符を全て消去して空五線にした状態でも、その情報の一部が内部にデータとして残っていることがある。ちりも積もれば何とやらで、これらのゴミが蓄積すると必要以上にファイル容量は大きくなり、画面表示やデータ処理の足かせになることもある。これは、Finaleを使って試行錯誤によって作編曲を行う人の場合、新規入力であっても起こりうることだ。

　意外と知られていないのだが、Finaleにはこの「ゴミ」を掃除してくれる機能がある。「書類メニュー(2006以前では「オプションメニュー」)＞データチェック＞ファイル・メンテナンス...」にて「削除した項目の完全破棄」以下の項目をチェックして「OK」を押すだけだ。

　なお、一番下の「ファイル整合性テスト」は、Finale 2001以前のデータを読み込んだ場合のチェック機能なので(詳細はマニュアルを参照)、最近のファイルを受け継いだ場合は、このチェックの意味はほとんどない。それどころか、ファイル中にライブコピーを多用している場合は、この「ファイル整合性テスト」を行うことでかえって楽譜がメチャクチャになる場合があるので要注意だ。

　もし、「ファイル整合性テスト」のチェックを外すのを忘れてファイル・メンテナンスを行い、楽譜がメチャクチャになってしまった場合は、速やかにアンドゥ(取り消し)を行おう。ゴミ掃除の前の状態に戻ってしまうが、再度「ファイル整合性テスト」のチェックを外してファイル・メンテナンスを行えば問題ない。Finaleを起動した状態では、この「ファイル整合性テスト」はオンになっているので注意が必要だ。
　「糠床方式」でファイルを受け継ぐ場合は、ファイル上の楽譜内容を全て消去したタイミングでファイル・メンテナンスを行うことをお勧めする。

　ポジティブな話題をと思っていたが、やっぱりネガティブな部分に触れざるを得ない状況になってしまった。純粋にポジティブな話題を書ける日はいつになるのやら......。

※ 11/3/22に記事追加

　Finaleは2007からIntel搭載のMacにも対応したUniversalアプリケーションとなった。ところで、最近の大規模なアプリケーションソフトは、本体とそれに付属するプラグインと呼ばれる小さなアプリケーションとで構成されているものが多い。それらはそれぞれ独立して開発されていることも多く、本体が新しいOSに対応していても、個々のプラグインの対応の足並みが揃わないという状況もしばしば発生する。
　Finaleの場合、プラグイン項目に入っている物の他、一見本体の機能のように見えるスキャナ読み取り機能やHuman Playback機能等も、じつはプラグインで供給されているものである(Mac OSならアプリケーション本体を「パッケージの中身を表示」で覗くとわかる)。実際、2007がリリースされた当初、スキャナ読み取り機能がIntel搭載Macに対応できていない旨のアナウンスがあった。

　さて、前置きが長くなってしまったが、じつは2008にも問題の生じるプラグインが残っている。そのひとつは「コーダ切れの作成」プラグインである。

　Intel搭載Macでこのプラグインを使ってコーダ切れを作ろうとすると、とんでもないレイアウトになることがある。使用する場所によっては、一見まともに機能しているように見えることもあるが、その場合でも、分断された左右の組段のバランスが正確にレイアウトされていないことが多い。

　こうなってしまっても、レイアウトツールでドラッグして修正することは可能であるが、そんな手間がかかってしまうのでは、そもそもこのプラグインを使う意味がない。
　このプラグインをまともに動作させたければ、FinaleをRosettaモード(PowerPC互換モード)で立ち上げるしか方法はない。手順は以下の通り。

1. 一旦Finaleを終了する。




2. FinderにてFinaleアプリケーション本体を選択し、「情報を見る」にて、「Rosettaを使って開く」にチェックを付けてダイアログを閉じてからFinaleを起動させる。このとき、チェックを付けただけでダイアログを閉じないままFinaleを起動しても、Rosettaモードに切り替わっていないので注意。


3. プラグインを使い終えたらFinaleを終了し、上記のチェックを外して再度Finaleを起動する。　

　他のプラグインでは、「作曲支援ツール＞共通音にタイをかける」がまったく動作しないことが確認されている。これもRosettaモードで起動すれば使用可能になる。

　それなら、いっそのことFinaleはつねにRosettaモードで使用すればいいじゃないかと思われるかもしれない。しかし、Rosettaモードでは、今度は「ページレイアウト・ツール」の「ページ・マージン編集パレット」と「組段マージン編集パレット」を表示させることができないというバグが確認されている。それと、Rosettaモードでは、Intelの特性を活かしたパフォーマンスは引き出せないことも覚悟する必要がある。
　Intel Macユーザーは、これらのプラグインを使いたいときだけ、Finaleを起動しなおさなければならない煩わしさがあるが、現状では仕方がない。

　Finaleに限ったことではないが、使用頻度の少ない機能のバグは長年放置されるきらいがある。2007で発生した「コーダ切れの作成」のバグが2008でも放置されているということは、このプラグイン自体が2006でやっと搭載されたという事実から鑑みても、あちらではあまりコーダ切れって需要がないのだろうか？　たしかに、あちらの楽譜では、コーダ部の五線を切らずにそのまま続けて書かれてあるものも多い。しかし、ライバルソフトのSibeliusでは、最初のバージョンからコーダ切れの機能が標準搭載されていることから(しかも、こちらの仕様の方が断然実用的！)、需要がないわけではなさそうだ。
　とある情報筋によると、もともとMacのソフトだったFinaleも、現在は世界的に見てもWindowsユーザーの方が圧倒的に多く、最近のソフト開発はWindowsが優先で、Macは後回しなのだという。シェアの少なさに加えてUniversalアプリケーションへの対応、バグ放置の原因はこのあたりにありそうだ。

---

11/3/22に追記

　Finale 2011でこのバグはやっと解消された。メデタシメデタシ。ただし、リンク・パートでこのプラグインが使えない問題は改善されず......残念。

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

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

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

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

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

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

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

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

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

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

※ 09/7/14に記事追加

　Finale 2007までは、コピーには小節単位モードと音符単位モードの２つのモードがあったのだが、2008からはこの垣根が撤廃された。これは歓迎すべきことなのだが、しかしまた、これも仕様の変更後にはしばし起こることだが、新たな困ったバグも生み出してしまったようだ。
　装飾音符のうち、小節線の直前に置かれる後打音を含む小節をコピーすると、その後打音は、次の小節の１拍目の前打音に勝手に置き換わってしまうのだ。これは、垂直方向へのコピーでも水平方向へのコピーでも同様である。

　不思議なことに、この現象は１本線のみの楽譜では生じない。しかし、五線を複数設けている楽譜では必ず発生してしまう。もちろん、ピアノのような大譜表も例外ではない。

　これを回避する方法としては、今のところライブコピーを使う方法が確認されている。以下に手順を掲げる。

1. ライブコピーモードでコピーを行う。



2. コピーされた小節については、「ユーティリティメニュー＞その他のユーティリティ＞ライブコピーを通常の小節に戻す」を使って通常の小節に戻す。

　ライブコピーした小節はそのままでもいいと思われるかもしれないが、このライブコピーもバグの巣窟と言われるくらい問題点を多く抱えているので、やはり通常の小節に戻しておくことをお勧めする。ライブコピーの諸々の問題点については......気力があれば、改めて述べるかもしれない(笑)。

　この問題点について、もっと別の解決法の情報をお持ちの方は、ぜひ報告をお願いしたいところである。

---

09/6/27に追記

　Finale 2010でこのバグは解消された。メデタシメデタシ。