Finaleのここがダメ! : 2008年7月アーカイブ

※ 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月以降に書かれたブログ記事のうちFinaleのここがダメ! カテゴリに属しているものが含まれています。

前のアーカイブはFinaleのここがダメ! : 2008年6月です。

次のアーカイブはFinaleのここがダメ! : 2008年8月です。

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