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

　2018年10月10日、Finale version 26(以降v26と表記)がリリースされた。v25がリリースされたのが2016年の夏、途中いくつかの無償のメンテナンスバージョンがリリースされ、軽微な機能改善も行われたが、最近のFinaleでは、本格的なメジャーバージョンアップは２年おきのサイクルになっているようだ。なお、v26の日本語版がいつリリースされるのかについては、本稿執筆時点ではまだMI7からの公式発表はない。

　v26の動作システム条件については、公式によればWindows版がWindows 7以上、Mac版ががmacOS Sierra(10.12)以上となっている。2009年に発表されたOS上で動くWindows版に比べ、Sierraは２年前に発表されたばかりのOSであり、１年毎にOSを更新するApple社の姿勢にも問題があるとはいえ、Mac版についてはあまりに条件が狭すぎると批判が出そうだ。ただ、我が家のEl Capitan(10.11)環境でも特にインストール時に跳ねられることはなく、今のところ特に問題なく動いている。Yosemite(10.10)環境ではどうかについてはまだ情報がなく分からない。仮にインストールできたとして、OS固有の不具合があっても、サポート外という扱いなのだろう。

　早速、v26の新機能についてレポートを行ってみよう。

機能強化されたアーティキュレーション
　今回の機能強化の目玉は何と言ってもアーティキュレーションである。Finaleはこれまでもバージョンアップの際に特定のツールに絞って大々的な機能強化を行ってきたが、今回はアーティキュレーションがその対象となった。

　これまでのFinaleでは、アーティキュレーションに配置の順位はなく、１つの音符に複数のアーティキュレーションを付けると、同じ位置に配置されてしまっていた(下図参照)。これを自動的に回避する方法はなく、衝突したアーティキュレーションはユーザーの責任において手動で修正するしかなかった。

　v26からは、アーティキュレーションの配置に順位が付き、同じ音符に複数のアーティキュレーションを付けると、自動的に並び替えてくれるようになった。

　この順位は「アーティキュレーション選択」画面の並びで決定される。ダイアログ上部の注釈にもあるように、リスト中の「＊」が付いたものが配置が考慮されるアーティキュレーションで、若い並びのものがより内側に配置されることになる。フェルマータは最も外側に配置されるものなので、従来より順位が繰り下がっていることが分かる。アーティキュレーションの配置の順番を変えたければ、このリスト上で項目を並び替えればよい。

　また、スラーとのコンビネーションも強化されている。これまでは、スタッカートなどのスラーの内側に配置されるアーティキュレーションのみが接触回避対象だったが、v26からはスラーの外側に付くアーティキュレーションについても考慮されるようになった。

　ただし、アーティキュレーション以外のエレメントとの衝突回避はスラーのみが対象で、同じ変形図形のトリルなどは自動回避の対象にならない。これは、発想記号などの他のツールで書かれたエレメントに対しても同様である。

　符頭側と符尾側でアーティキュレーションの配置を独立してコントロールできるようになった。これで、ヨーロッパの楽譜に多い、スタッカートを符尾側に付ける際は符尾に揃えて配置するという流儀にも対応できる(日本では符尾側でも符頭にセンタリングさせる流儀が一般的)。ただし、複合アーティキュレーション(後述)を別々に付けている場合、配置に矛盾が生じるケースがある。

　これまでのFinaleでは、全音符にトレモロを付けると意図しない位置に付いていた。これは、符尾側に付くアーティキュレーションの配置については符尾の先端が基準になっていたため、先端より内側に配置されるトレモロの場合、符尾のない全音符では基準点を飛び越して反対側に配置されてしまうことが原因である。こうしたトレモロについては、手動で修正するか、もしくは全音符のためだけに独立した設定のトレモロを別途定義して適用するしかなかった。

　この問題はv26でやっと解決された。

　v26からは、このトレモロの配置のためだけに設けられたともいえる、"On Stem" という新たな配置設定が加わり、これを選択したときだけに現れるパラメータもある。この設定により、従来のトレモロに設定されていた "Always Stem Side(日本語版では「符尾側」)" が設定されているアーティキュレーションは皆無となり、もはやこのパラメータは過去のデータとの互換性のためだけに残されることとなった。

　さらには、トレモロの数によって自動的にステムの長さが調節されるようになった。ステムの長さは、上記のパラメータの中の「符頭からの距離」と「符尾、旗、連桁の端からの距離」とトレモロの数によって決定される仕組みだ。

　このように、今回のバージョンアップでは、アーティキュレーションの機能が格段に改善されたわけだが、残された問題点もある。
　アーティキュレーションにはメゾスタッカートやスタッカートアクセントなど、２つ以上の記号が組み合わされたものがある(ここでは便宜的に複合アーティキュレーションと呼ぶことにする)。これまでのFinaleでは、たとえばメゾスタッカートのスタッカートとテヌートを別々に付けると上記のような衝突が発生していた。それ以前に、スタッカートとテヌートなどを別々に付けるのは煩わしいことから、Finaleにはあらかじめ１つのキャラクタとしてまとまっている複合アーティキュレーションが用意されていた(下図のハイライトされたもの)。

　浄書のルールでは、スタッカートやテヌートのような五線内に配置可能なアーティキュレーションは、符頭に一番近い線間に順番に配置されなければならないわけだが、上記のようにデザインが固定されたアーティキュレーションでは、それぞれの記号が分離できないため、浄書的には誤った配置になってしまう。

　この問題は、v26からはそれぞれのアーティキュレーションを個別に付けることで完全に解決する。

　さて、ここで疑問を持った方もいるだろう。そう、旧来の１つのキャラクターで表現されている複合アーティキュレーションの扱いだ。
　v26では、v25以前のファイルを読み込んだ際に、楽譜中のアーティキュレーションの配置を新仕様にアップデートするかどうかを尋ねてくる(環境設定にてこのダイアログをスキップさせることも可能)。

　ここで、アーティキュレーションを新仕様に更新する選択をした場合、旧来の複合アーティキュレーションがどう扱われるのかという興味が涌く。個々のアーティキュレーションに分解されて正しく配置し直されることをかすかに期待したが、はたして複合アーティキュレーションの扱いには何の変化も起こらなかった。
　v26以降のアーティキュレーションにも、旧来の１つのキャラクタで表現する複合アーティキュレーションは依然用意されている(最初のほうのダイアログ参照)。旧ファイルとの互換性のために残したという大義名分もあるだろうが、この複合アーティキュレーションが用意されている限り、ユーザーは正しい配置のためにアーティキュレーションを別々に付けることよりも、一発で複合アーティキュレーションが付けられる簡便さを選ぶだろう。その結果、残念なことだが、今後もこうした誤った記譜の楽譜は世に出回り続けることになる。

　では、Finaleはどうすればよかったのだろうか。
　答えは簡単だ。２つ以上のアーティキュレーションを同時に付けられるようにすればよいのである。たとえば、アーティキュレーション選択画面で、複数のアーティキュレーションを選択可能にするのでもよいし、マクロが定義されていれば、複数のマクロキーを押したまま付けられるというのでもよいだろう。技術的にもそんなに難しいことではないはずだ。
　さらに願わくば、旧来の複合アーティキュレーションを個別のアーティキュレーションに分解して正しい配置にしてくれるユーティリティ、ないしはプラグインを用意して欲しい。このままでは、Finaleはせっかく複合アーティキュレーションを正しい配置にできる手段を設けたのに、それを有効利用できないでいることになる。

　ちなみに、今回のアーティキュレーションの強化は垂直方向の配置のみに限定されているので、アルペジオ記号の臨時記号を避けてくれない等の、水平方向の配置に関する従来からの問題点は何ら改善されていない。アルペジオ記号の配置はアーティキュレーションの中でも特殊であり、本来なら一般的なアーティキュレーションとは独立した制御が必要なエレメントと言え、今回強化が見送られたことは理解できなくもない。v26のアーティキュレーション設定のパラメータ名のうち、これまで単に "Positioning:" だったものをわざわざ "Vertical positioning:" と断っているのは、今回の強化が垂直位置に限定したものだったということもあるだろうが、将来 "Horizontal positioning:" も加えるという布石にも取れる。新興ソフトDoricoの完璧と言えるほどのアルペジオ記号の制御を見てしまうと、Finaleにも奮起を促したくなるが、v26.5あたりで実現されることを期待する。

　今回のアーティキュレーションの改善点は、後発ソフトのSibeliusやDoricoでは初期バージョンから解決されている部分であり、Finaleがこれらのソフトの後塵を拝している数ある弱点の１つとなっていた。したがって、昨今の楽譜作成ソフトの能力を知るものにとっては、今回のアーティキュレーションの機能強化は決して目新しいものではなく、これでやっと競合ソフトとスタートラインに並んだに過ぎない。

その他の改善
・小節の直接指定
　従来のFinaleでは、スクロール表示やスタジオ表示においてはドキュメントウィンドウ左下のボックスにて小節数を指定できるが、ページ表示ではそこはページ指定になり、小節を指定することはできなかった。v26からは、いずれの表示モードにおいても、Windowsではctrl+shift+G、Macではcommand+shift+Gにてダイアログが現れ、そこで指定できるようになった。

・デフォルトファイルやテンプレートファイルの発想記号、コードサフィックス、変形線形が大幅に追加されている。
　選択肢が増えた分、目的の記号を探すのが大変になってしまうが、よく使うものにはショートカットであるマクロを設定しておくとよいだろう。

・インストール時に、v25のアンインストールを選択できる。もちろん、残しておくことも可能。

・Mac版の高解像度ディスプレイでのパフォーマンスを改善。
　これまでも高解像度ディスプレイを使うと特定の動作が遅くなるという指摘が多く寄せられていた。私は依然古いモニタを使用しているので、高解像度ディスプレイでのパフォーマンスは体験できないのだが、このあたりの問題点についてはかなりの改善が行われたようだ。
　ただ、以前も指摘したことがあるが、高解像度ディスプレイが一般的になってきている今日日、操作に直接かかわる部分ではないとはいえ、インターフェイスの所々に未だに白黒２値のビットマップ画像が使われ続けているのはいかがなものか。

・MusicXMLが強化された。
　MusicXMLについては、メンテナンスバージョンのアップデートの際にも、その都度多岐にわたって改善がなされている。多分に技術的なことなので、具体的な改善点について知りたい方はオンラインマニュアル(英語版)の該当項目を参照されたい。現在、楽譜記述の共通言語であるMusicXMLの開発はFinaleの開発元のMakeMusicが行っているわけだが、こうしてMusicXMLの精度の向上に心血を注ぐ背景には、新興の競合ソフトの台頭を踏まえ、それらのデータをFinaleに高精度で取り込めるようにすることでユーザーを囲い込みたいという思惑も感じられる。

　上述のとおり、今回のバージョンアップでは、アーティキュレーションの機能強化以外に特筆すべき改良点は見られず、改訂は限定的なものにとどまっている。前回のバージョンアップでは、記譜部分に革新的な改善はなく、少々肩すかしを食らった気分だった。その後まもなく、先進的な操作性を備えた楽譜作成ソフトDoricoがリリースされたことは記憶に新しい。
　現在のFinaleの最大のウィークポイントは、楽譜のエレメントの衝突に対して多くの部分で対応できていないことだ。しかし、他の競合メジャーソフトは現在そのあたりを確実にクリアしている。商用版下制作業者ならともかく、一般的なユーザーは、そんな衝突回避の調整ために時間を費やしたくはないだろう。そこを自動的に調整してくれるソフトがあれば、みんなそちらに流れてしまうのではないだろうか。
　Finaleの次のメジャーバージョンアップは２年後だろうか。少なくとも、エレメントの衝突については、ツール単位での対応などという悠長なことをやっていてはダメで、次回までにほぼ解決されていなければ、新規ユーザーの獲得はおろか、古参ユーザーからも見切りを付けられるだろう。MakeMusicにはそのくらいの危機意識を持って開発に当たっていただきたいものである。

　今回は、頭の隅にでも記憶しておけば、たまには役に立つかもしれないという小ネタである。

切れた複前打音を効率よくつなぐ方法
　Finaleの装飾音符には妙な癖がある。高速ステップ入力で複前打音を入力する際、連桁が自動的につながるときとつながらないときがあるのだ。次の譜例をご覧いただければすぐに気付かれた方も多いと思うが、これは連桁グルーブと密接な関連がある。

　Finaleでは拍単位で連桁グループが形成され、デフォルト状態では連桁は拍ごとに自動的に切れるようになっている。複前打音の装飾音は、連桁グループの内部にある場合は自動的につながるが、連桁グルーブの最初のものはつながらない。小節の最後にある後打音の場合も同様だ。これは明らかに上述の仕様に基づくものと考えられるが、ステップ入力においてはいかなる場合でも装飾音符の連桁は自動的につながるわけで、ここにもFinaleの設計のちぐはぐさがみられる。
　この複前打音の連桁をつなぐためには、高速ステップ編集枠内で「/」キーにてつなぎ直すしかないのだが、その作業が１、２箇所ならともかく、大量に出てきた場合はうんざりだ。これを一発でつなぐ方法はないものだろうか。じつは簡単な方法がある。連桁をつなぎたい部分を選択した後、「ユーティリティメニュー＞連桁の再連結＞歌詞に従って再連結...」を選択するだけだ。

　ただし、上記の結果をご覧いただけばお分かりの通り、この方法には、拍や連桁グループの設定に関係なく、連結可能な連桁はことごとくつながってしまうという問題がある。ダイアログのオプションにある「拍子記号で設定された拍の切れ目でも連桁を切り離す」にチェックを入れれば済む話ではないかと思われるだろうが、残念ながら、ここにチェックを入れると高速ステップ入力での入力時と同じ判断がなされ、結局状況は何も変わらないのである。
　以上のことから、この方法は、結果的に連桁を切る作業のほうが増えてしまうかどうかを慎重に勘案した上で運用すべきだろう。

　なお、当然のことながら、歌詞が割り付けられている音符については、本来の機能どおり、シラブルに従って連桁が切断されてしまう。もっとも、このような複前打音が多量に使われる歌曲はあまりないと思われるし、あったとしても、装飾音符にまでシラブルが振られることは通常考えられないので、運用上の問題はないといって差し支えないだろう。

切れたままの２、４拍目の連桁
　上記に関連してもうひとつ小ネタを。
　「ファイル別オプション - 連桁」の「４分の４拍子で８分音符４つを連桁で連結する」にチェックが付いていても、その連桁グループに１つでも装飾音符が含まれていると、ステップ入力、高速ステップ入力にかかわらず、このオプションは無効になってしまう。どうやら、Finaleは装飾音符が絡むと、拍単位の連桁のグループ化を優先するらしい。

　特に、２、４拍目頭に装飾音符がある場合、高速ステップ入力にて、２、４拍目にカーソルを置いて「/」キーをタイプしても連桁はつながってくれない。「ユーティリティメニュー＞連桁の再連結＞指定する拍子によって再連結...」にて2/2拍子にして再連結をしてみても同様である。

　じつはこの場合、２、４拍で「/」キーをタイプしたのち、その直前の装飾音符上で「/」キーをタイプしてやっと連桁がつながるのである(順番はどちらが先でもよい)。つまり、内部的には、連桁グループ内の装飾音符を含むすべての音符の「連桁接続フラグ」をオンにしなければ、連桁はつながらないのである^(※注)。

　ただ、この方法の問題点は、片方の「連桁接続フラグ」をオンにしただけでは何の変化もなく、どちらのフラグがオンになっているのかは画面上では確認できないことである。この方法が分かりにくければ、装飾音を挟んだ両方の音符の範囲を選択し、冒頭で示した「歌詞に従って再連結」を利用したほうが堅実である。

　これは、Finaleの分かりづらい仕様の１つで、実際、つなぎ方が分からなかったのか、はたまた単なるずぼらからなのか、２、４拍目の連桁が不自然に切れたままの楽譜をしばしば見かける。このようなユーザーを困惑させるような仕様は早急に改善して欲しいものである。

多難なFinale 2014日本語版の船出
　去年(2013年)の11月、本家アメリカで２年ぶりのバージョンアップ版2014がリリースされ、その日本語版は３ヶ月後の今年(2014年)２月にリリースされた。これまでは日本語版が発売されるまでには、ローカライズ作業のために半年近いタイムラグが発生していたことを考えると、輸入代理店のMI7も今回はよく健闘したと言えよう。
　ところが、その日本語版2014がリリースされるやいなや、ネット上のあちこちから早速購入したユーザーからの悲鳴が上がり始める。「旧バージョンのファイルが開かない」といったものから、「保存したはずファイルが消滅した！」という悲痛な叫びまで......。実際、明日レコーディングというスコアが消滅してしまい、レコーディングに穴を空けてしまったという話や、ほぼ書き終えていた卒業作品をリリースされたばかりの2014を使って仕上げていたところ、ファイルが突然開けなくなり、作品提出期限に間に合わず留年を余儀なくされたという音大作曲科学生の悲劇もあった。
　ユーザーがこうした不利益を被った場合、ソフトメーカーに責任を問いたくなるのはやまやまだが、大抵のソフトにはインストール時に表示される約款に「ソフトのバグによるユーザーの損害についてメーカーは一切の責を負わない」旨が明記されていて、Finaleも例外ではない。それに同意してインストールを行っている以上、法的にはメーカーに責任は問えないことになっているのだ。一見理不尽に思えるが、なぜそういうことになっているかについては、「ソフトウェア、製造物責任法(PL法)」などをキーワードに検索していただきたい。
　とはいえ、「ファイルが開かない」、「保存したファイルが消滅する」などというバグは、ソフトウェアとしては商品価値を失うレベルの致命的な欠陥であり、これが一般製品ならリコール対象になっても不思議はない。いくらバグについてはメーカーに法的に責任がないとはいえ、このような欠陥ソフトを販売することには道義的な責任が生じるだろうし、結果的にメーカー自身が評判を落とすことになる。

　MI7も４月になってようやくこの問題に対する暫定的な対応策を自身のサイトのFAQで発表するに至ったが、根本的な解決には、プログラムを開発している本家MakeMusic社(以下MM)からのアップデートを待つよりなかった。2014は他にも多くの重大なバグを抱えていたようで、そうこうしているうちに、MMからは2014b(英語版)のアップデータのアナウンスがあり、それは6月3日にリリースされた。
　2014bには前バージョンのアップデート版2012cのような目新しい新機能はなく、アップデート内容はバグフィックスがほとんどだったが、その2014bに対しても早速ユーザーから問題点が次々に指摘され、約１ヶ月後の7月7日、矢継ぎ早に2014cのアップデータをリリースした。一方、国内代理店のMI7は、当初日本語版のアップデータについては2014bを７月中にリリースするとアナウンスしていたが、それに先んじて本家で2014cが出たため、結局2014bを飛ばした2014cのアップデータという形で７月末ギリギリでのリリースとなった。
　結果論だが、ここまで重篤な問題があったことを考えれば、日本語版2014はもう少しじっくりと動作の検証をした上で、問題をクリアできた時点でリリースすべきだったかも知れない。リリースを急いだことがかえって仇となってしまった格好だ。

　さて、「保存したファイルが消滅する」というトラブルは本家のフォーラムでも報告されており、日本語版固有の問題というわけではなかったのだが、「ファイルが開かない」というトラブルは、文字発想記号に日本語フォントを使っている場合に発生することが判明しており、こちらは日本語版固有のトラブルである。Finaleが日本語のフォント名を正しく認識できないことが原因で、この問題そのものは以前のバージョンから存在していた。

　この日本語フォントの誤認識によってファイルが開かなくなるトラブルについては、当初MMから「あまりにプログラムの根幹部分にかかわる問題なので、2014のアップデートでは対応できない」旨の回答があったようだが(MI7の当該FAQの下部参照)、MI7は５月に主宰したFinaleユーザーの集いの場にMM社の営業担当者を招き、ユーザーの面前でこの問題の2014のアップデートでの解決を確約させたという。営業担当者としては大勢のユーザーの面前で自社製品のネガティブな発言はしにくいわけで、この演出がMI7とMMとの馴れ合いによるものかどうかは第三者の私には知るよしもないが、MI7もなかなか知謀を巡らせたものである。

未解決の日本語版の問題点
　というわけで、日本語フォントの誤認識の問題については晴れて2014cで解決が図られたわけだが、今回のアップデートで日本語処理に関する問題が一挙に解決されたわけではない。少なくともMac版2014cでは、今なお以下のような問題を抱えている(Windows版については検証できないので、以下の問題点は発生しないかも知れないし、全く別の問題が発生している可能性もある)。

①セットアップ・ウィザード１ページ目において、日本語表記が含まれる楽器編成を削除すると大抵クラッシュする(英数文字のみの編成名だと問題ない)。クラッシュしないケースでも、その際に出るアラートの楽器編成名が文字化けする。

②「五線ツール」、「ステップ入力ツール」、「高速ステップ入力ツール」を選択した状態では、ことえりやATOKなどのインプットメソッドが機能しない。すなわち、この３つのツールを選択している間は、「ファイル情報」でのタイトルなどの入力、文字列の検索、各種ファイルの保存などの際に日本語が一切タイプできない。いずれも他のツールを選択しなおせば解決するが、「五線ツール」を選択しないと操作できない「楽譜スタイル名」や「グループ名」の入力には対応できない。
　いずれのケースもコピー＆ぺーストによる日本語入力は可能なので、これらに日本語を使いたい場合は、あらかじめ別の場所(外部テキストエディタでも可)でタイプしたものをコピー＆ぺーストすることで対応するしかない。これはFinale 2014cで新たに発生した問題。

③発想記号のカテゴリ用表示セットのセット名に日本語をタイプしても、最初の２〜３文字しか表示されず、それ以上の文字をタイプするとクラッシュする。

④発想記号の「五線別に割り付け」、反復記号の「五線別表示リスト」に日本語の名称を付けると文字化けしてしまう。2011以前にここに日本語名を付けたファイルを開いた場合も文字化けを起こすので要注意だ。

⑤Mac版では、オーディオファイルの書き出し時に、ファイル名や保存場所のパス名に日本語が含まれているとファイルが生成されない。この問題についてはMI7のFAQにも書かれている。

　①、③、④は2012から発生しだしたバグであり、このバージョンからは、おそらく日本語にローカライズすると文字化けを起こしてしまうためか、英語のまま表示されるダイアログやアラートが散見されるようになった。2012といえばユニコードに対応したバージョンだが、それに伴うプログラムの変更が行われた結果、これらの新たな問題が発生したと考えられる。

　じつは、2012からは「組段の間隔調整」というプラグインがバンドルされているのだが、Mac版についてはこの文字化けの問題が未解決らしく、それから２年以上も経った2014cにおいてもなおバンドルされていない。一応Mac版についてもマニュアルは準備されているが、ダイアログは英語のままであり、マニュアルのプラグイン・メニュー項目からも外されている状態だ。

なぜ日本語に関するトラブルはなくならないのか？
　Finaleの日本語に関するトラブルは昨日今日に始まったことではない。なぜ、日本語に関するトラブルは根絶できないのか？

　Finaleほどの多機能なソフトになると、機能ごとにプログラマーが開発を分担するのが一般的である。そうした場合、各プログラマーが勝手にプログラムを作ると全体の整合性がとれなくなるので、ソフト開発全体を俯瞰し統括するマネージメントが必要となってくる。しかし、Finaleを操作していると、そのマネージメントが適切に行われているのか疑問視される箇所がいくつも散見される。
　その一例がマクロの登録方法だ。発想記号では、2009の改訂時に記号の選択画面を表示させたまま続けて別のマクロキーを登録できるように改良された。ならば、アーティキュレーションなど他のツールでのマクロの登録も同様に改良されているかと思いきや、こちらは新たなマクロキーを登録するたびに一旦ダイアログを閉じて楽譜に戻らなければならないという従来のインターフェイスのままだ。同じような編集に対し、ツールによって異なる操作を求められるこのようなインターフェイスはユーザーを混乱させ、習熟を妨げるだけである。
　同様のことが日本語処理についても言える。上記で指摘した③と④は、ユーザーが登録した名称がリストに現れるというものだが、「カテゴリ用表示セット」では入力欄、リスト表示とも日本語で表示されるものの、入力時にクラッシュを引き起こし、「五線別に割り付け」ではクラッシュこそ起きないものの、入力した日本語は入力欄、リスト表示とも文字化けを起こす。「五線別表示リスト」では入力欄の文字化けは起こらないが、リスト表示は文字化けを起こすといったように挙動が三者三様である。ちなみに、同様の処理を行う発想記号の「カテゴリ名」や「付箋の編集」では日本語は問題なく表示されている。

　こういった一貫性のなさは、各プログラマーが自分の担当部分のみに恣意的なプログラミングを行っている証左である。このような問題は、「共通した処理は共通したプログラムを組む」という基本を徹底させておけば防げることであり、これが見通しのよいプログラムを作る鉄則なのだが、それをおろそかにすると、ひとたび問題が起こった場合に、その原因の究明が困難になり、その場しのぎの対応をした結果、さらなる問題が発生するという悪循環に陥ることになる。
　ご存じとは思うが、Finaleの日本語版のローカライズは日本語版の登場以来ずっと国内代理店が行っており、本家MMは直接ローカライズにはタッチしていない。したがって、本家MMは日本語環境下での動作チェックを積極的に行っているわけではなく、日本語版固有のトラブルが起こる度に、国内代理店からの報告を受けてプログラムの修正に応じているに過ぎない。MMはこれまでさんざん日本語に関するトラブルの報告を受けてきたはずだが、今もなおそのトラブルが一向に根絶できないことを鑑みるに、MMは日本語処理に関するトラブルについてはその場しのぎの対応しかせず、そこにプログラムの根本的な見直しを行おうという姿勢は全く感じられない。上記MI7のFAQにある、発想記号に日本語を使った際のトラブルに対する当初のMMの回答がまさにそれを物語っている。

　日本語に関するトラブルが根絶できないもうひとつの理由は、日本語版ユーザーが圧倒的なマイノリティであるということにもありそうだ。
　公式な数値が出ているわけではないが、以前、輸入代理店の人から聞いた話では、Finaleの世界全体のシェアに対する日本語版ユーザーの割合は１割にも満たないという。私は２割くらいはいるのではと思っていたので、この数字は正直意外だった。
　Finaleは各国語にローカライズされているが、漢字を含む２バイト圏の日本語版以外はすべて英数文字からなる１バイト圏のヨーロッパ言語版だ。例えば、もし我々日本人が作ったソフトに対して、文字を右から左に向かって書くアラビア語圏のユーザーから「文字がちゃんと打てない」というクレームが届いたら、「そんな環境のことなんか知らないよ」となるだろう。MMの開発者からすれば、日本語に関するクレームに対する感覚はこれに似たものではないだろうか。
　今回の2014cのアップデートでの改善項目は、Windows版が約60項目、Mac版については約100項目に及んでいる。その項目の多さには驚かされるが、その筋の人の話によれば、Finaleクラスの規模のソフトでは、つねにその10倍近い未解決のバグや潜在的なバグを抱えているという。次バージョンの開発や膨大な数のバグ修正に追われる中で、１割にも満たないマイノリティユーザーのためだけに、根本的なプログラム修正を行っている余裕などないというのが正直なところかも知れない。

　先日、MM社がスポーツトレーニングのサポートソフトを開発しているPeaksware社の傘下に入ったという発表があった。なんでも、MM社のもうひとつの主力製品である伴奏アシスタントソフト、SmartMusicとの連形を模索するという。このことが今後のFinaleの開発にどう影響するのかは未知数だが、我々としては、より良い開発環境の構築に結びついてくれることをただただ願うばかりである。

※ 13/6/22に「問題点３」を追記

　「レガシー」と聞くと、真っ先に車のブランド名を思い浮かべる方も多いかもしれない(正式なブランド表記は「レガシィ」)。「レガシー」とは「過去の遺産」の意味だが、ことITの世界では「レガシー・デバイス」や「レガシー・システム」といったように、もっぱら「時代遅れなもの」というネガティブな意味合いで使われる言葉である。80年代後半に産声を上げたFinaleには、その当時の設計思想に基づく「レガシー」な部分がまだあちこちに残っている。今回はそんな中の１つである「弱起」についてスポットを当ててみることにする。

　2000年代初頭までのFinaleの弱起は、「バグの巣窟」と言われるほど多くの問題を抱えていた。パート譜に書き出すと弱起小節内の連符がご破算されて音符が消滅するとか、「Allegro」等の発想記号が１拍目より左に移動できず、拍子記号に揃えることができない等々......。当時のユーザーの間では「Finaleの弱起機能は使うな」が共通認識だった。その後、そうしたバグは少しずつ修正されて現在に至っているのだが、弱起そのものの根本的な設計が脆弱なため、今もなおいくつかの問題を残している。

問題点１：曲頭にリピートで戻ると、余計なカウントが入ってしまう
　Finaleの弱起は特殊な構造になっている。「ライブコピー・ツール」を選択すると、弱起小節に見慣れない図形が表示されていることに気付くだろう。これは「空白時間の挿入」が行われている小節を示すアイコンである。では、その「空白時間の挿入」とは何ぞや？

　「空白時間の挿入」機能とは、例えば４拍子の曲で３拍の不完全小節を作りたい場合、小節の頭に１拍の「空白時間」を挿入し、表記上はその部分を詰めることで見かけ上の不完全小節を表現するというしくみである(詳しくはマニュアルをご覧いただきたい)。初期のFinaleでは、弱起を含む不完全小節は「空白時間の挿入」を用いて表記するのが標準的な方法だった。ただ、読んで字のごとく、プレイバックを行うとまさに「空白時間」、すなわち空カウントが挿入され、記譜通りのプレイバックにはならない。次の譜例のように曲頭に戻るリピートを作成した場合、曲頭に戻った際に余計なカウントが挿入されてしまう。

問題点２：記譜上の誤り
　2011以前のFinaleでは、弱起小節のデフォルトの休符は全休符のままだった。これが原因で、オーケストラのリハーサル現場が混乱した光景を私は幾度も見ている(もちろん、私自身はそんなヘマをしたことはないが)。2011になってやっとデフォルトの休符は正しい音価で表示されるようになったのだが、これまで全休符で表示されていたものをそれぞれの音価の休符に置き換えただけで、位置は依然小節にセンタリングして配置されている。弱起部分が短い場合は気付きにくいが、下の譜例のように弱起部分にスペースを必要とする場合には、その奇妙な配置にすぐに気が付くだろう。これは記譜としては明らかな誤りである。
　この配置を正しくするためには、デフォルトの休符が表示されている部分に改めて休符を入力するという、じつにナンセンスな作業をする必要がある。

　楽典では弱拍とそれに続く強拍の休符をまとめてはならないというルールがある。しかし、Finaleの弱起のデフォルトの休符は１つの休符でしか表現できないため、本来まとめてはならない休符がまとまった状態で表示される。以下の譜例の弱起部分の休符の表記はいずれも楽典的には誤りである。これを正しい表記にするには、やはり実際に休符を入力しなければならない。

　別の問題もある。
　セットアップ・ウィザードから新規作成する場合、セットアップ・ウィザード上では１つの音符で表現可能な音価の弱起しか扱えないため、それ以外の音価、例えば下記の譜例のような弱起を表現できない。

　なお、Finaleの名誉のために断っておくが、上記のような弱起はあくまでセットアップ・ウィザードでは設定できないのであって、書類メニューの「弱起の設定」を使えば不可能ではない。ここではパレットによる音価の指定の他に、音価を直接数値で指定することもでき、上記の譜例では弱起は８分音符５つ分なので、８分音符の長さである512EDU×5＝2560EDUを直接指定すればよいことになる。惜しむらくは、音価を表すEDUという単位はあまり馴染みがなく、もっと直感的な指定ができるようにして欲しいところではあるが。

　ところが、Finaleの弱起小節のデフォルトの休符は１つの休符でしか表現できないという設計上、８分音符５つ分という音価の休符を表現することはできず、代わりに近似値の音価の休符が表示される。この状態のままパート譜を作ってしまうと演奏者の混乱は必至なので要注意だ。結局この場合も正しい休符をユーザーの責任において入力しなければならない。

　弱起小節に相応の休符が自動的に表示されるようになったことは、つねに全休符で表示されていた2011以前よりは一歩前進と言えるかもしれないが、実際に休符を入力しなければ正しい表記にならないという点では2011以前と何ら変わりがない。そもそも弱起小節の休符が１つの休符でしか表せないという設計自体に無理がある。早急な改善を望みたいところである。
　なぜこんな事を口やかましく言うかというと、2011の弱起の改訂以降、デフォルトの休符のまま出版されている楽譜を目にすることが多くなったからである。この原因はFinaleの不完全な仕様にあることは論を俟たないが、少なくとも出版社たるもの、プロとして正しい楽譜表記についての見識を持つべきである。

問題点３：「スラッシュ表記」でのバグ　※ 13/6/22に追記
　10年以上前にCoda社(MakeMusicの当時の社名)に送ったバグや要望をまとめた報告書を改めて読み直していたところ、弱起部分で「スラッシュ表記」を行うと、本来の拍子(４拍子なら４拍分)のスラッシュが表示されてしまうという記述を見つけた。この件について改めてFinale 2012で検証してみたところ、余計なスラッシュこそ表示されなくなっているものの、まだ問題を残していることが分かった。以下にその問題点を示してみる。

　ドラムパートの弱起部分をスラッシュ表記にするために「五線ツール」で小節を選択する。弱起小節全体を選択しているはずだが、すでに選択域がおかしい。

　楽譜スタイルの「スラッシュ表記」を適用したところ。後半に片寄って表示されている。スペーシングをかけ直しても変化なし。

　弱起小節の他のパートに音符を入力すると、スペーシングは正常に戻った(厳密には完全ではないのだが)。

　......と思いきや、ドラムパートをパート譜表示にしてみると、依然、片寄ったまま。

　音符(休符)を入力すればスペーシングは直りそうなので、とりあえず休符を入力してみる。

　楽譜スタイルの「スラッシュ表記」を適用すると、今度は不必要にスペーシングが広がり、しかも、休符のゴーストまで現れる。このゴースト、スクロール表示では最上段パートの拍子記号の直後に、ページ表示ではページの下端に現れる。弱起小節に入力した音符/休符がゴーストとして現れるようだが、元の音符/休符を非表示にしてもゴーストは消えない。

そもそも現行の弱起設定は必要か？
　弱起は曲頭で生じるとは限らない。弱起で始まる曲は、曲中の段落部分や繰り返し部分も弱起表記になることが多い。また、テーマが弱起で開始される変奏曲は、基本的に各変奏も弱起で開始される。さらには、最近のFinaleでは、ファイルの統合機能が設けられたり、曲の途中でも楽器名をフルネーム表示できるようになるなど、複数の曲を１ファイルに入れることを想定した設計になってきている。すなわち、弱起は１つのファイル中のあらゆる部分に出現する可能性がある。

　Finaleのマニュアルの「不完全小節」の項目を見ると、曲頭以外の弱起を含む不完全小節は、拍子記号設定の「表示専用に別の拍子記号を使う」方式で作成せよと書かれている。また、プラグインを使って小節の途中に反復記号を挿入した際などに生じる不完全小節にも、こちらの方式が用いられている。そもそも、Finaleの弱起がバグだらけだった頃は、冒頭の弱起についてもこちらの方式で表現することがユーザーの間でも推奨されていたくらいである。

　現在の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の不完全な設計のせいで、多くのユーザーが不毛な修正作業を強いられるか、もしくは修正されないままの不適切な楽譜が世に出回り続けるかのどちらかである。開発元にはこれらの根本的な解決に本腰を入れてもらいたいものだ。