finale Version 26 64bit

finale Version 26 64bit

Version26より機能強化されたアーティキュレーション

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

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

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

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

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

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

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

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

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

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

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

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

この問題は、v26からはそれぞれのアーティキュレーションを個別に付けることで完全に解決する。
　
さて、ここで疑問を持った方もいるだろう。そう、旧来の１つのキャラクターで表現されている複合アーティキュレーションの扱いだ。
Version26では、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に高精度で取り込めるようにすることでユーザーを囲い込みたいという思惑も感じられる。