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

　Finaleがバージョンアップされる際には、それまでのバージョンが抱えていたおびただしい数のバグも修正されていることが多いのだが、一方で機能の強化や変更が思わぬバグを誘発させることもある。こういったバグはユーザーがある程度使い込んでから発見されることも多く、バージョンアップ後の比較的初期段階に見つかったものについてはマイナーアップデートで対応されることも多いが、対応しきれなかったバグについては次のバージョンに持ち越されることになる。
　現在Windows版は2011b、Mac版は2011cまでのアップデータが配布されているが、海の向こうの開発元は既に次期バージョン2012のベータテストを開始している時期であり、この時点でこれ以上の2011のアップデータが出る可能性は低い。現時点で確認されているバグについて以下に挙げておこう。

日本語歌詞が正しく割り付けられないバグ
　舶来ソフトの宿命とも言えるFinaleの日本語環境固有のトラブルは今日に始まったことではないが、今回もそんなバグが発生している。
　Finale 2011レビュー(1)でも既に触れたが、2011からリニューアルした歌詞編集ウィンドウ内に日本語歌詞を書いた場合、歌詞の途中から「クリックで割り付け」にて割り付けようとすると、カーソルを置いた文字とは異なる歌詞が割り付けられてしまう。このバグについては、日本語版がリリースされてから早期にユーザーからクレームが来たらしく、早速イーフロンティアのFAQにも報告されている。

　日本語ばかりの歌詞を入力している場合、実際にタイプされる文字は歌詞編集ウィンドウ内のカーソルを置いた文字より冒頭からおよそ2/3の位置の文字が割り付けられることに気付いた人もいるだろう。なぜこのようなことが起こるのか。
　日本語の部分は内部的には２バイトの文字コードで表現される。Finaleの歌詞ではひとつのシラブル(ひとつの音符に割り付けられる歌詞)に所属する文字は、通常日本語１文字＋区切り記号の半角スペースキャラクタの計２文字なのに対して、文字コードは３バイトが割り当てられることになる。もうお分かりかと思うが、Finaleは歌詞編集ウィンドウ内では文字数で勘定をしているのに、実際に割り付ける文字は文字コードのバイト数で勘定をしているのだ。上記の例では「さ」の冒頭からの文字数が21番目なのに対し、21番目の文字コードは「き」の次の半角スペースにあたり、そのシラブルに所属する「き」の文字が割り付けられたという按配である。これは、クリックを続けていくと、歌詞編集ウィンドウ内のハイライト部分が実際に割り付けられる文字とだんだんずれていくことからも分かる。その結果、上記の歌詞編集ウィンドウでは、スペースキャラクタを挟んだ２文字分がひとつのシラブルとしてハイライトされてしまっている。

　上の例では分かりやすくするために、ひとつのシラブルにつき１文字が対応するものとして説明をしたが、実際の歌詞では「しょう」などのように１つのシラブルに複数の文字が割り当てられたり、１バイト文字の欧文歌詞が混在することもあり、事情はもっと複雑である。それでもこの文字コードの仕組みを踏まえれば、正しい文字が割り付けられるよう歌詞編集ウィンドウ内でカーソルを置く位置を逆算で求めることも不可能ではないが、そもそも歌詞をタイプする度にそんな不毛な計算を強いられるのはナンセンスである。結局日本語歌詞を書く場合、イーフロンティアのFAQにも書かれているとおり、「クリックで割り付け」機能を使う場合は歌詞の先頭から順番に割り付けていくか、歌詞編集ウィンドウを使わずスコアに歌詞を直接タイプするしかない。
　文字数と文字バイト数が完全に一致する１バイト言語圏において、開発者がこの２バイト文字のことを全く考慮しなかったことは致し方ないところだが、こういうトラブルが起こる度に日本のユーザーは割を食うことになる。Finaleも、そろそろ言語環境に左右されないUnicodeへの対応に本格的に取り組んで欲しいものだ。

「符頭の変更」にて一部のキャラクタが変更できないバグ
　選択した範囲の特定の符頭を一括して変更するには、「ユーティリティ＞変更＞符頭の変更...」を使う方法が効率的だが、ここで「選択した符頭：」にスロット番号130以降のキャラクタを指定すると、変更されず無視されるか、または意図したものとは異なるキャラクタに変更されてしまう。符頭キャラクタは後半のスロット番号に多く含まれているので少々厄介である。

　代替策としては以下の２通りが考えられるが、いずれもユーティリティーにある符頭変更機能を完全に代用できるものではないことに留意する必要がある。

1. 「プラグインメニュー＞音符関係＞符頭の変更...」を使う方法。なお、こちらの方法では選択範囲の符頭を種類に関係なく一括して変更してしまうので、選択範囲の２分音符のみを変更したいといった用途には使えない。その場合は2.の方法を検討していただきたい。


2. 「道具箱ツール」の「符頭変更ツール」か「符頭微調整ツール」を使う方法。なお、こちらの方法では１小節単位での編集しかできないという制約がある。

　どうやら英語版ではこのバグは発生しないようなので、こちらも日本語環境が影響している可能性が高い。

　その他、2011以前よりずっと放置されたままのバグも結構残っている。さらに新たなバグが発見された場合はここで追加報告したい。

　Finale 2012で上記のバグはすべて解消された。メデタシメデタシ。

　　　　

なぜ2008/2009/2010なのか？
　Finale User's Bible(以下FUB)の初版は2003/2004/2005が対象、改訂２版は2005/2006/2007が対象とくれば、改訂３版は2007/2008/2009が対象となるのではないかと心待ちにしていた方もいたかも知れない。なぜ１年空けて2008/2009/2010となったのか？

　その話をする前に、改訂２版を刊行した際にあったちょっとしたエピソードを紹介しておこう。
　現在のところ、前版のFUB 2005/2006/2007のAmazonの紹介ページにこの本に対するレビューはないが、じつは、かつてこの本がリリースされてしばらく経った頃、星２つ(１つだったかも)の辛口レビューが掲載されていたことがあった。結局そのレビューは１ヶ月くらいの期間掲載されたのち削除されたわけだが、その内容を要約すると「新版が出たので買ってみたが、ほとんど内容は同じ。高い金を出して買って損した。初版を持っている人は買う必要ない」というものだった。このレビューを書いた人の憤懣も分からないでもないが、この人はちょっと勘違いをしている。
　ソフトウェアはバージョンアップ行うことで少しずつ機能強化を図ってゆくものであるが、それは枝葉末節な部分であり、根本的な操作体系というものは基本的には変わらないものだ(Finaleの場合はそれが足枷となってしまっている部分もあるが)。したがって、操作が変わらない部分については、バージョンがいくら上がろうが、それに関する記述を変えようがない。
　一方、Finaleは毎年バージョンアップを重ねているソフトであり、バージョンアップ時にソフトの操作が少しでも変わってしまえば、以前の操作手順を載せた本に技術書としての価値はなくなってしまうわけで、いくら大本に変更がなくても、その差分を更新した解説書はやはり必要になる。仮に操作に全く変更がなかったとしても、書名に対象バージョンを明記している限り、そのバージョンより新しいものが出た時点で、その本の旬は過ぎてしまう。日進月歩のコンピュータ関連の技術書が負う宿命といえる。
　辞典も数年おきに改訂版を出す。しかし、改訂されている部分は全体の一割にも満たないだろう。その辞典に対して「内容がほとんど同じじゃないか、けしからん！」と憤慨する人はまずいないだろう。この手の本はその一割に満たない改訂部分に価値があるのだ。おそらく上記のレビュワーが１ヶ月そこらで上げた拳を降ろしたのは、お門違いの自分の主張に気が付いたからだと思われるが(Amazonが不適切として削除するような過激な内容でもなかったし)、著者の一人としても何ともバツの悪い出来事ではあった。

　話を戻そう。
　改訂３版を出すにあたって、執筆者の間でも、2007/2008/2009として出すべきかどうか検討が行われた。
　まず１つ目の問題として、2008、2009の２度のバージョンアップでは、Q&A項目が劇的に変化するような機能の改訂は行われず、内容的に目玉となるような目新しい情報を盛り込めそうにないことが挙げられた。いくら一部分しか更新されないのが技術書の宿命とはいえ、やはり上記のAmazonのレビューのようなそしりは受けたくないものだ。
　そして２つ目の問題。Finale 2008からはブロック編集メニューが消滅し、そこにあった項目は編集メニューとユーティリティメニューに分散された。FUBでは、バージョンで操作が異なる部分はバージョンごとの説明が行われているのだが、この旧ブロック編集メニューがらみの編集はFUBの根幹を成すといえるほど広範囲に及び、2007と2008を両方扱った場合、記述は煩雑になり、紙幅もいたずらにかさんでしまう。
　じつは、FUBのページ数が初版本の419ページから改訂２版の564ページに一気に150ページ近くも増えたことに対して、出版社の方から、第３版はこれ以上ページ数を増やしてくれるなとのお達しが来ていた。確かに、改訂２版では初版より紙を若干薄くして対処したとはいえ、かなりのボリュームの本となっている。現実問題として、これ以上本を厚くすると使い勝手も悪くなるに違いない。
　結局、２つ目の問題が一番のネックになり、FUBを2007/2008/2009として出すことは見送られたのである。

　現在、FUB 2008/2009/2010のAmazonの紹介ページには、星５つの好意的なレビューが掲載されている。そのレビューは、私がここで釈明しようとしたことを見事に見透かして代弁しており、私自身、自分が提灯レビューを書いたと疑われまいかと案じたくらいである。いやはや、このレビューを投稿した人には恐れ入るばかりである。

新執筆陣
　FUBは、その前身である秋山公良氏が単独で著したFinale Bibleの流れを汲んでいる本であり、FUBの初版の際も秋山氏が中心になって企画立案＆執筆が進められた。しかし、その後秋山氏はFinaleのライバルソフトであるSibeliusの方にすっかり傾倒してしまい、最近は自分が教鞭を執る大学の授業でFinaleを使っている程度で、プライベートではほとんど使わなくなり、バージョンアップの度に改訂される新機能について行けなくなったという。「機能を把握していない者が執筆しても仕方がない」という理由で、自ら執筆陣からの離脱を申し出てしまった。
　FUBは私を中心に企画が進められることになり、これを機に新しい血を入れてみたくなった。そこで、執筆者の一人である黒川氏の紹介で、ネット上などでFinaleのサポートを精力的に行い、プレイバック方面にも明るい神尾立秋氏を新たに迎入れることにした。彼の担当した「トップノートの表示方法」などは、Finaleを知り尽くしていないと編み出せないじつにスマートな方法で、私も目から鱗だった(もし、私がそれを担当していれば、誰もが容易に思いつく陳腐な方法を紹介してしまうところだった)。FUBの大部分を担当している私と黒川氏は、どちらかというと浄書家視点で方法論を構築するきらいがあるのだが、神尾氏は我々とは異なる視点でFinaleと接しているのだろう、我々からすると思いがけない方法論を提示したりしてじつに興味深い。

　ところで、今回は私だけが「編著」となっている。私が中心となって原稿のとりまとめを行ったこともあるが、DTP作業も私一人で全部やってしまったことも理由のひとつだ。
　原稿のとりまとめについては、第２版の時も実質私が行っていたのだが、第２版までのDTP作業は秋山氏が行っている(奥付に制作協力としてAkiyama Music Designと記されている)。私もかつて音楽出版社の出版部で編集を行っていたことがあり、以前よりDTP作業はそれなりにこなしてはいたのだが、500ページを超える本丸々１冊を組んだのは初めてで、元来遅筆なことに加えて、目次や索引の作成などいろいろ不慣れなことも手伝って、結局当初予定していた５月の出版から大幅に遅れてしまった。
　それでも、自分で本を組むというのはいろいろメリットもある。FUBはとにかく譜例や図版をたくさん盛り込んでいるので、そのレイアウトは頭を悩す部分である。他人の原稿を組んでいると、最後の数行とか譜例だけがポツンと次のページに送り出されることもしばしば起こる。他人の原稿を勝手に削るわけにも行かないので、そんなときは、行間や文字間をうまく調整してページ内にうまく収めるわけだが、こと自分の原稿の場合は、うまく収まるように文章を削ったり、逆に白みが多いページは文章や図版を足したりといった調整が自在にできるのである。おかげで、今回の第３版は、文章がページをまたぐといった部分は最小限にとどめることができたと自負している。
　とはいえ、一般の人がFinaleを使ってそこそこうまく作った楽譜も、プロの浄書家が見れば、スペーシングや記号類の配置の甘さなどを指摘されるのと同様、私がInDesignのほぼデフォルト設定で組んだこの本など、組版のプロから見ればおそらくツッコミどころ満載であろう。このサイトなどを読んでみると、私ごとき組版の素人が本をレイアウトするなんぞ笑止千万という高笑いが聞こえてきそうである。
　「餅は餅屋に任せろ」という諺がある。この本のレイアウトもプロのDTPデザイナーに任せるという選択肢もあったのだが、結論から言うと、そうした場合、編集は複雑になり、出版はさらに数ヶ月遅れていただろう。痛し痒しである。

なぜFUBの図版はほとんどMac版なのか？
　じつは、これは出版元の音楽之友社の編集者から訊かれた質問である。これに対して「読者からクレームでも来ているのか？」と逆に尋ねたところ、「そういうクレームは一切来ていない」とのこと。しかし、クレームとはいかないまでも、Windowsユーザーからすればちょっと気になることかも知れない。

　理由は大したことではない。執筆者がみんなMacユーザーだからである。もしWindows環境を持たない私がFinaleのWindows版のキャプチャを撮ろうとすれば、Windowsユーザーの誰かに頼まなければならない。その際、ダイアログの数値や設定もこちらの指定通りに再現してもらわなければならない労力を考えると、FUBの膨大な図版のキャプチャを他人に頼むなどということは、人間関係の崩壊にもつながりかねない由々しき問題であることがお分かりいただけるだろう。
　それと、Windowsユーザーの方には申し訳ないが、同じダイアログのキャプチャを並べてみれば、最新のWindows 7であっても、残念ながらその美しさはMac OS Xのそれには到底及ばない。美しい楽譜を追求しようとする本であるからには、そこに使われる図版もすべからく美しくあるべきである。
　さらにもうひとつ。世の中のFinaleのWindows版とMac版のシェア争いでは圧倒的にWindowsに軍配が上がる。実際、Finaleに関する解説本の多くにはWindows版の図版が使われている。一方、楽譜浄書の現場では、DTPとの連系の良さという理由から圧倒的にMacが使用されている。FUBは作編曲家だけではなく、プロの浄書家にも携えてもらいたい本であり、そういう意味でも、一般の解説本とは異なるスタンスでありたいと考えているのだ。

　まあ、後半になるほどじつはどうでもいい理由なのだが(笑)、あえて理由を挙げるとすればそんなところだろうか。
　じつはFUBでは、Windows版とMac版で操作が異なる場合は、Windows→Macの順に説明を行う決まりになっていて、一応Windowsユーザーに配慮がなされている(配慮といえるほどのものでもないが)。

第４版はいつ出る？
　先のことはそのときになってみなけりゃ分からないというのが私の持論だが、まあ実際のところ、これもFinale 2012の内容次第である。もし、2012がメジャーバージョンアップで操作に大幅な変更があれば、当然2010/2011/2012対象として出すべきだろうが、マイナーバージョンアップに終われば、今回と同様、１年見送る可能性もありえる。
　第４版を出すとすれば、内容的にも何か違う視点を盛り込みたいとも思うのだが、ページ数の制約もあり、今のところまったく白紙である。やはり、そのときになってみなけりゃ分からない(笑)。
　一方、電子書籍も一般化しつつあるこのご時世、紙媒体でのリリースがベストなのかどうかもそろそろ考える時期に来ているかもしれない。２、３年後はまだしも、10年後のこの手の技術書は、差分を頻繁に更新でき、PDA端末等に映し出されるデジタル媒体になっている可能性は非常に高い(そんなことよりFinale 2020は存在しているのか？)。
　「楽譜を紙に印刷して使う」というアナログな光景はしばらく続きそうだが、それもそのうち電子譜面台に映し出されるようになるのかも知れない。そもそも、パソコンで楽譜を作るという概念自体、もっと違うものになっている可能性が高いのだから。