バグ情報 : 2008年7月アーカイブ

　ここのブログ記事も、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では上記のフレックス・スラーの不安定さが完全に解消されたようだ。これは、我々浄書家にとっても多少の福音となるか......。