
|
Studio ftn Score Editor Classic 6.x の開発状況を報告します。
あらすじ
![]() 2009-01-30
そしてあっという間に画面部品が完成した。 あまりにあっさり完成したため、どうしてよいか分からず途方にくれている。 たまたま、頭の調子が良かったようで、運が良かった。 下手したらとても複雑で不安定な画面部品が出来上がるところであった。 そんな事も無くとてもシンプルに出来上がったので安心して先に進める。 画面部品ができたのでドラム譜設定画面に組み込みを行った。 あまりにあっさり出来たのでこれから何をしてよいか決まっておらず、 これから、開発作業手順を書き出したい。 それと、パートの上下幅の設定がドット単位なので分かりにくいと思う。 そうではなく、加線の本数を指定するように変更する事にした。 そうすると、旗の飛び出た部分の長さが合わなくなるので、 領域を自動設定しようとしていたが、加線の本数が勝手に変わると困る。 しかし、これも、あっさりとすばらしい解決方法が見つかった。 そのおかげで、加線の本数指定方法が実現できる事となった。 頭の調子がたまたま良く、本当に運が良かった。 さらに、記号情報を取得できるよう大改良した効果が出て、 これから作成する画面の描画がとても簡単になる。 もし、あの時やっていなかったら、今頃苦しんでいたはず。 これに関しても運が良かった。
以前、この画面を追求した結果、 アーティキュレーション画面そのものである事が判明しているので、 実際は、アーティキュレーション画面の開発となる。 せっかくなので、ドラム以外のアーティキュレーションが対応できるよう、 今まで、沢山の改善修正を行ってきた訳である。 結果的に7でやろうと思っていた作業と同等であり、避けて通れず、 結局、7の機能を部分的に6.xに組み入れるに至った。最低限の準備が整った。 この画面を開発する前に、独自の Win コントロールを先に開発する必要があるので、 その作業を行う事にする。
改善作業は、出戻り作業というで事もあり、目新しい事は無く、 むしろ、現在のバージョンと完全に同等な動作をするよう復元する作業は、 面白みがなく苦しい作業である。 しかしながら、コツコツ進めてきて、あと1週間くらいでこれらの復元が完了する。 これが終われば、ドラム譜の改善に進める。 今回の改善で内部構造がかなり洗練された。 繰り返しの1番括弧などの線の長さも自由に調節できるようになった。 オクターブ記号も同様。 どうせ全ての記号を作り直すのであるから、今まで対応できなかった、 前打音の加線を対応したり、細かい部分も改善した。 あと、以前から、4分休符の形状が不自然だと思っていたので、 グラフィックの改善も行った。8分音符の旗も付点に重なっていたのが、 以前から気になっており、旗のグラフィックも改善した。 という訳で、見た目に関してもいくつか改善された。 気泡・・・。 話は関係ないが「気泡」に苦しんでいる。 ディスプレイの紫外線カットフィルターを購入したものの、 画面に直接貼る仕組みのものしか無く購入。 しかし、ほんのわずかな埃があるだけで、その部分に、 2cmの気泡が出来るのである。これを手作業で貼るのは鬼のような苦しみ。 その見た目の醜さはひどい。欠陥商品としか言えない。 なぜ、昔のように透明の板式のものが売っていないのか不満である。 あまりに見た目がひどいので、5分もたたず取り外してあきらめる事にした。 しかし、翌日、そこそこの値段だったので、あきらめきれず、 アクリル板にシートを貼り付ける試みで何度もトライした。 努力の結果気泡が10個ほどまでに少なくなった。 これを可能にする技術がガムテープである。 シートについた埃を丹念に1つ1つガムテープで除去していく。 気泡が出来たら、シートをはがしガムテープで埃を除去。これの繰り返しで、 なんとか10個までに抑える事に成功した。 アクリル板側の埃をシートに移し、シートの埃をガムテープで取るのである。 気分転換がしたい時にでも、1つ1つ埃を取っていこうと思う。 最終的には無くなるはずである。 ただ、何度も付け貼りした関係で、シートのふちの部分が変形してしまった。 その部分の気泡はあきらめるしかない。
アーティキュレーション記号は、種類によって、またがるか、そうでないか、 いろいろであるが、どのような記号でも、潜在的にまたがりの性質を持たせた。 記号のメニューから、その能力を引き出すか無効にするか指定できるようにした。 基本的に、アーティキュレーション記号は、またがり無効が初期設定である。 これにて、アーティキュレーション系の記号もまたがり対応が終わった。 ただ、またがりが無い場合、装飾として動作するものと継続記号として動作するものが存在。 この切り替えは、定義画面で決める事にする。 ともかく、難関を1つクリアした。 しかし、パートデータの大改造等で、いろいろな細かい動作がOFFになった状態である。 新しいデータ構造で、それらOFFにしてある処理も動作するよう修正しなければならない。 細かい物は好みであるが、目に見えない細かいものは好きでない。 これからの修正は後者となり、気が遠くなる。 目に見えないような内部的な細かい修正をコツコツしていく必要がある。 それらが全て終われば、エディタ部分が新しい機能が増えつつ、完全に復活する。 まずは、これを行う必要がある。 それを避けて先に進もうとしたら、ものすごくしょんぼりしてきた。 頭の中で気になってしかたないからである。なので、避けて通れない。 先に、細かい復元が終わらないと、安心して、先に進めない。 それらが終われば、ドラム譜の設定画面に取り掛かれる。 この画面のために、これだけ、いろいろな修正を行ってきたのである。
また、この時の描画に関しては一時的に若干不自然になるが、機能的に支障がないため、 最終調整の際に検討したい。先に優先すべき開発を進めてしまいたい。 ともかく、大枠、またがり記号の組み込みが完了した。 次に進みたい。 いよいよ本番のアーティキュレーションに関してのまたがり対応である。 ユーザが自由に文字を決められるという事は、 またがり記号なのかそうでないのか、またがりかたの違いなどを考慮する必要がある。 またがりの記述もいろいろあるのが厄介なのである。 これを、ユーザが定義するのか、どのような記号でもまたがりの性質を持たす事ができるのか。 このあたりで、モヤモヤしている。モヤモヤ状態で進めると混乱するといった経験があるため、 何が気に引っかかっているのか突き止めなければならない。 これには時間がかかりそうである。 モヤを解消する手段として、空想でなく、ひたすら紙に全てのパターンを書いて、 事実を見る作業が有効だと思う。ユーザ思考で実際にどう使用するかを書いていく。 たとえ理論的に可能でも、使う頻度が極めて稀であれば、その仕様の優先は下げて考えていく。 もっとも良く使用する操作を優先して考えていく。
再び、中断していた、またがり記号の開発に戻るとする。 行き詰っていた、またがり記号に伴う改ページ等の処理も簡単に完了。 基本的な、またがり関連は完了した。 残すは、またがりの細かい部分。1つは、選択記号をカーソルでずらす仕様の対応であるが、 またがり記号の場合、範囲までずれてしまうし、移動によっては、範囲がマイナスになる。 この問題を回避する仕様がなかなか思いつかない。 更に、またがり記号を選択した時の描画が不自然になる問題も残されている。 機能上は問題ないが、見た目が問題。 この2つが解決すれば、またがり記号の残りの細かい部分はすんなり進むと思われる。
現在、パートデータ構造の大修正作業を行っているが、 直接思考の発見により、7の試作を行っていた段階よりも、さらに分かりやすい構造にする事ができた。 確実に、無駄なソースコード量が減っていくのが分かる。 今までの構造はバージョン1から受け継がれてきた構造であるが、 なぜこれほどまでに面倒な構造になっていたのか不思議なくらいである。 おそらく、長年の楽譜式ソフトの開発の経験によって、 適した構造が分かるようになったのかもしれない。
そこで、パートのデータ構造を、やはり変更すべきか検討してみたい。 結局バージョン7でやろうとしていたデータ構造にするべきか検討する事となる。 6.xとはいえ、結局バージョン7を開発しているのと同等である。 やはり、避けて通れない部分がある。最終形態を目指すとすれば、 いずれ、パートのデータ構造を7にする必要が出てくる。 2度手間になるくらいなら、今回やってしまうべきである。 バージョン1〜6までのデータ構造のほうが良いか7のほうが良いか。 検討する時が来た。当然時間軸系の記号を対応するには7にするしかないような予感もする。 今までやってきたことは無駄ではない。全ての考えが生かされているし、 断片的な考えが1つにまとまろうとしているのである。
またがり記号の連動処理はかなり作業量があり面倒。 UNDOも加えると、かなり細かい。あらゆる操作をした場合でも、 またがり記号の整合が取れなければならない。 結果的に気が遠くなった。しかし、気が遠くなる原因は脳が付いていけないだけである。 脳は、あまりに多くの関連する事を一気に処理できないようである。 Aを考えBを考えCを考えるとAがあいまいになっていく。 Aを考えるとBやCがあいまいになる。結果的に全部あいまいになる。 これが、気が遠くなる現象。こうなると、たとえ運良くA,B,C,の開発が100%であったとしても、 脳は不安なので、100%が信じられず、Aを壊したりし始める。 これを回避するには、紙に書く事である。 現在のプログラムで、どのような操作が実現できたのかを、全て書き出すのである。 たとえば、マーカを次の小節に動かして、次の小節を削除、マーカは前の小節に移動し小節が削除される。 言い換えると、マーカがある小節の削除機能を対応した。という事になる。これで1機能。 こうやって、可能な操作方法を全て書き出す。対応できていない部分が見つかれば対応する。 こうやって、書き出す事で、いずれ、全体の法則性が見つかる。もし、見つかれば、 その法則を満たしているプログラムであるかを検証する。 きちんとプログラムが出来ていれば、他の紙に書いていないパターンも動作する可能性が高くなる。 プログラマが見つけられなかった操作は、バグ報告され、そのとき対応パターンを追加するのである。 ともかく、またがり記号の開発は大変である。こんな所で足止めされたくないが、 仕方がない。ここはしっかりと取り組みたい。 ![]() |