2008年7月アーカイブ

 ここのブログ記事も、Finaleのネガティブな話題ばかりを提供していると、読者を暗澹たる気分にさせてしまい、「ユーザーのFinale離れを起こさせたのはあのブログのせいだ!」などと後ろ指を指される事態はぜひとも避けたいので、たまにはポジティブな話題......「Finaleの知っておくとお得情報」をTIPSカテゴリで提供していこうと思う。

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

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

FileMaintenance1.jpg

 私の最近書いた吹奏楽の楽譜の「ファイル情報」を見たところ
Finale 3.0(1994年)から受け継がれていることが分かる

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

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

FileMaintenance2.jpg

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


FileMaintenance3.jpg

「ファイル整合性テスト」を行ってメチャクチャになった楽譜

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

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

※ 11/3/22に記事追加

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

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

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


coda1.jpg

コーダにしたい冒頭の小節を選択して「コーダ切れの作成」プラグインを適用すると......

coda2.jpg

とんでもないレイアウトになってしまった

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

  1. 一旦Finaleを終了する。


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

  4. プラグインを使い終えたら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でこのバグはやっと解消された。メデタシメデタシ。ただし、リンク・パートでこのプラグインが使えない問題は改善されず......残念。

※ 09/6/27に記事追加

 最近の高機能のたいていの楽譜作成ソフトには、打楽器の楽譜上の音符と実際に鳴らす音源との関連付けを行う機能が搭載されている。Finaleの場合はパーカッション・マップがそれである。プレイバックに関与しない浄書専門のユーザーにはほとんど利用価値はないが、Finaleで楽譜を打ち込みながら音を確認したい大多数のユーザーにはなくてはならない機能である。
 打楽器の表記は、作編曲家によっても出版社によってもさまざまである。そのような多様なニーズに応えるひとつとして、パーカッション・マップには、特定の楽器に特定の符頭を割り当てるという機能がある。これを利用して入力すれば、自動的にシンバル系は×符頭、トライアングルは△符頭で表記させるといった使い方ができるようになる。


pmap1.jpg


 ところが、この一見便利に見える機能にも落とし穴がある。パーカッション・マップでは、各楽器について黒玉用と白玉用の符頭をそれぞれ定義できるのだが、通常の符頭を使おうと思った場合、白玉用符頭は1種類しか定義できないので、2分音符用の白玉か全音符のどちらか一方しか割り当てることができないのだ(通常、2分音符用の白玉が割り当てられている......上記ダイアログ参照)。この状態で楽譜を書くと、下のような奇妙な楽譜になってしまう。


pmap2.jpg

 これを修正するには、全音符のみを個別に変更するしかないのだが、まず、スコア全体の入力が完了した後、パーカッション・マップを使用しているパートのみを選択し、「ユーティリティ・メニュー(2007以前なら「ブロック編集メニュー」)>変更>符頭...」にて「検索:」「変更:」ともに「選択した符頭」に全音符を指定すれば簡単に一括変換できる。もちろん、選択範囲に別の符頭キャラクタの全音符を使用している場合は、その部分は選択範囲から外す必要があるが。


pmap3.jpg

pmap4.jpg

正しい表記になった

 浄書的には、通常の全音符に2分音符の符頭を使うというようなことは金輪際あり得ない。しかし、手書きの楽譜の場合、「白丸に符尾が付いていなければ全音符」という暗黙の了解があるから、とりあえずこの表記でも演奏現場で混乱が起こることはまずないという実態がいっそう事を曖昧にさせている。一般のユーザーに上記の修正法を周知させたところで、「別に読めるからいいじゃん」と煩わしさを理由に放置されるのが目に見えている。

 実際、作編曲家の書いたスコアがそのまま無批判に出版される傾向のある、ある分野の出版物にこの奇妙な記譜を頻繁に見かけるようになってきた。他の記事でも書いたが、特定のソフトの妙な仕様のせいで、正統的な書法が軽んじられ、妙な書法がスタンダードになってしまうことは残念なことだ。



09/6/27に追記

 同じ憂慮を抱いていたユーザーの声が届いたのか、Finale 2010からは、扱える符頭が全音符、倍全音符まで拡張された。メデタシメデタシ。しかし、旧ファイルの設定をそのまま受け継いで使っている場合は、全音符、倍全音符の部分は旧来通り2分音符の符頭のままで、自動的に全音符、倍全音符符頭にコンバートされるわけではないので注意が必要である。

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


slur1.jpg

フレックス・スラーをオフにした状態

slur2.jpg

フレックス・スラーをオンにした状態

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

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


Slur3.jpg

下段のスラーは、臨時記号との衝突を避けたためにこのようにふくらんでしまった。

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

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


Slur4.jpg

適切な形をしているスラーも......

Slur5.jpg

表示倍率を変えるとまったく違う形になることがある。

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

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

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

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

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

 次の譜例をご覧頂きたい。極めて普通に見られるリズムだが、じつは、Finaleはこの楽譜を書くことができない(正確に言えば、書けなくはないのだが、面倒な作業を必要とする。詳細は後述)。意外に思われるかもしれないが、これもFinaleの変な仕様のひとつだ。


a. beampattern1.jpg


 Finaleには、上記の譜例のような16分音符以下の連桁が休符を挟む場合の、内側の連桁をどう処理するかというオプションがある。


beamoption1.jpg

 このオプションをオンにすると、16分音符同士の内側の連桁はつながれるが、つながる相手のいない不完全連桁まで伸びてしまう。


b. beampattern2.jpg

 一方、このオプションをオフにすると......


beamoption2.jpg

 左側のパターンの不完全連桁の方は正常だが、16分音符同士の内側の連桁は分断されてしまう(そういうオプションなのであたりまえだが)。


c. beampattern3.jpg

 しかし、そもそもc.の右側のような連桁パターンはありえるのか? 少なくとも、信頼のおける老舗の出版社の楽譜ではこの形はお目にかかった記憶がない(しらみつぶしに探せばあるのかもしれないが)。普通に考えても、手書きで楽譜を書く場合、わざわざc.のような面倒な書き方をする人はいないだろう。浄書の書法もそのルーツは手書き譜にあることを考えれば、このパターンの場合も、内側の連桁がつながったa.(b.)が本来の形と考えるのが自然である。

 じつは、この内側の連桁をつなぐオプションはFinale 2000から設けられたもので、それまでのFinaleでは無条件でc.のパターンになっていた。a.のように内側の連桁をつなぎたければ、「連桁伸縮ツール」でちまちまと伸ばしていくしかなかったのだが、この作業を疎んじた人、あるいは浄書のセオリーに疎い人は、c.の状態の楽譜をそのまま世に出した。90年代からc.のパターンが巷で目に付くようになったのは、Finaleにもその一因がありそうだ。

 では、こんなオプションなどわざわざ設けずに、デフォルトで無条件でつながるようにすればいいじゃないかと思われるだろうが、そうもいかない事情がある。もしそうした場合、今度は2000以前に「連桁伸縮ツール」を使って調整した連桁が正しく表示されなくなるのだ。つまるところ、このオプションは過去のデータと互換性を取るためにだけに存在しているのである。Finaleには、このような過去の負の遺産を現在までずっと引きずっている部分があり、それがユーザーを混乱させる一因にもなっているわけだが、このあたりについては、またの機会に改めて述べることにする。

 というわけで、このオプションは本来なら常にオンにしておくべきなのだろうが、そうするとなぜか、b.の左側の連桁パターンのような楽譜としてあり得ない表記を生じさせてしまう。楽譜中に一方のパターンしか出てこないのであれば、そのパターンが正しくなる設定を選んでおけばいいが、両方のパターンが混在する場合、一方を正しい表記にしようとすれば、もう一方の表記が正しくなくなるという、「こちらを立てればあちらが立たず」状態になってしまうのだ。

 実際、この問題に遭遇した場合は、次のいずれかの方法で修正するしかない。


  • チェックをオンにした状態(b.)......「連桁分断ツール」を使って、不必要に伸びた不完全連桁を切断し、「特殊連桁ツール」を使って、残った断片を8分音符の連桁の位置に重ねて隠す。

  • チェックをオフにした状態(c.)......「連桁伸縮ツール」を使って不完全連桁を相手側の位置まで伸ばす。

 どちらの方法を使うかは、修正を要するどちらの連桁パターンが少ないかで判断するしかない。このあたりはFinale User's Bibleに詳細な手順が載っているので、興味のある方はそちらをご覧頂きたい。 

 現在もなお、正統な形であるa.の状態にするには上述のとおり面倒な作業を必要とする。しかし、浄書家ならともかく、一般的に作編曲でFinaleを使う人にまでこの作業を強いるのは酷なことだ。結局のところ多くの人は、あり得ない表記を引き起こすb.を避けて、それよりはまだましということでc.のスタイルを選択することになる。
 一定のシェアを持った特定のソフトの妙な仕様のせいで、正統的な書法が軽んじられ、妙な書法がスタンダードになってしまうことは残念なことだ。

このアーカイブについて

このページには、2008年7月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2008年6月です。

次のアーカイブは2008年8月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。