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

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

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

　たとえば、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を起動した状態では、この「ファイル整合性テスト」はオンになっているので注意が必要だ。
　「糠床方式」でファイルを受け継ぐ場合は、ファイル上の楽譜内容を全て消去したタイミングでファイル・メンテナンスを行うことをお勧めする。

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

　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アプリケーションへの対応、バグ放置の原因はこのあたりにありそうだ。

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

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

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

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

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

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

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

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

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

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

※ 09/7/14に記事追加

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

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

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

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



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

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

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

---

09/6/27に追記

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