Studio ftn Score Editor Classic 6.x の開発状況を報告します。

あらすじ
小節またがり記号の描画に成功した。 範囲マーカを動かしたりする時の連動処理を開発中。 連動関係の開発は他の機能との関連性が多く、 頭では処理できない。こういう場合、操作できうる可能性の全ての操作を、 紙に書き出す事が重要である。

どうにもパートのデータ構造に疑問を感じ、検討を始める。

パートデータ構造の改善を行う事を決意した。 いずれクレッシェンドの対応で苦労すると判断した。 2度作るなら今1回だけ作るほうが後々楽だ。

パートデータ構造の改善が完了した。 その修正に伴い、エディタ操作、描画、UNDOなどの作り直しも終わった。 データ構造変更により、思いのほか簡単な構造になった事を実感した。

大枠、またがり記号の組み込みが完了した。 これをアーティキュレーション記号にも適用する。 しかし、何かがモヤモヤして、心配だ。 モヤを解消する手段として、空想でなく、 ひたすら紙に全てのパターンを書いて、事実を見る作業が有効だ。

アーティキュレーション系の記号もまたがり対応が終わった。 パートデータ構造修正に伴い、OFFにしていた機能の復元を行う。

繰り返しの1番括弧などの線の長さも自由に調節できるようになった。 前打音の加線を対応したり、細かい部分も改善した。 4分休符の形状が不自然だと思っていたので改善した。

ディスプレイの紫外線カットフィルターを購入したものの、 気泡に悩まされる事となる。何とか根気で気泡を除去する方法を見つける。

改善修正による修復作業が大枠終わった。 ドラム譜設定画面の改善に入る。 その実現にあたり、独自の Win コントロールを先に開発する必要がある。

Win コントロールの開発は困難を予想していたが、 ちょっとした発想の転換で、現状の画面部品をちょっと加工するだけで、 同等のものが実現可能な事に気が付いた。 画面部品ができたのでドラム譜設定画面に組み込みを行った。

ところで、パートの上下幅の設定がドット単位なので分かりにくい。 加線の本数を指定するように変更する事にした。


2009-01-30
    独自 Win コントロールであるが、開発がかなり難しいと思っていて、 気が遠くなっていたのであるが、 ちょっとした発想の転換で、現状の画面部品をちょっと加工するだけで、 同等のものが実現可能な事に気が付いた。

    そしてあっという間に画面部品が完成した。 あまりにあっさり完成したため、どうしてよいか分からず途方にくれている。 たまたま、頭の調子が良かったようで、運が良かった。 下手したらとても複雑で不安定な画面部品が出来上がるところであった。 そんな事も無くとてもシンプルに出来上がったので安心して先に進める。

    画面部品ができたのでドラム譜設定画面に組み込みを行った。 あまりにあっさり出来たのでこれから何をしてよいか決まっておらず、 これから、開発作業手順を書き出したい。

    それと、パートの上下幅の設定がドット単位なので分かりにくいと思う。 そうではなく、加線の本数を指定するように変更する事にした。 そうすると、旗の飛び出た部分の長さが合わなくなるので、 領域を自動設定しようとしていたが、加線の本数が勝手に変わると困る。 しかし、これも、あっさりとすばらしい解決方法が見つかった。 そのおかげで、加線の本数指定方法が実現できる事となった。 頭の調子がたまたま良く、本当に運が良かった。

    さらに、記号情報を取得できるよう大改良した効果が出て、 これから作成する画面の描画がとても簡単になる。 もし、あの時やっていなかったら、今頃苦しんでいたはず。 これに関しても運が良かった。
2009-01-29
    改善修正による修復作業が大枠終わったので、 6.x本題のドラム譜設定画面の改善に入りたい。

    以前、この画面を追求した結果、 アーティキュレーション画面そのものである事が判明しているので、 実際は、アーティキュレーション画面の開発となる。 せっかくなので、ドラム以外のアーティキュレーションが対応できるよう、 今まで、沢山の改善修正を行ってきた訳である。 結果的に7でやろうと思っていた作業と同等であり、避けて通れず、 結局、7の機能を部分的に6.xに組み入れるに至った。最低限の準備が整った。

    この画面を開発する前に、独自の Win コントロールを先に開発する必要があるので、 その作業を行う事にする。
2009-01-26
    記号データやパートデータやメニューの大改善を行ったため、 その修復を行っている。

    改善作業は、出戻り作業というで事もあり、目新しい事は無く、 むしろ、現在のバージョンと完全に同等な動作をするよう復元する作業は、 面白みがなく苦しい作業である。

    しかしながら、コツコツ進めてきて、あと1週間くらいでこれらの復元が完了する。 これが終われば、ドラム譜の改善に進める。

    今回の改善で内部構造がかなり洗練された。 繰り返しの1番括弧などの線の長さも自由に調節できるようになった。 オクターブ記号も同様。

    どうせ全ての記号を作り直すのであるから、今まで対応できなかった、 前打音の加線を対応したり、細かい部分も改善した。

    あと、以前から、4分休符の形状が不自然だと思っていたので、 グラフィックの改善も行った。8分音符の旗も付点に重なっていたのが、 以前から気になっており、旗のグラフィックも改善した。

    という訳で、見た目に関してもいくつか改善された。


    気泡・・・。

    話は関係ないが「気泡」に苦しんでいる。 ディスプレイの紫外線カットフィルターを購入したものの、 画面に直接貼る仕組みのものしか無く購入。 しかし、ほんのわずかな埃があるだけで、その部分に、 2cmの気泡が出来るのである。これを手作業で貼るのは鬼のような苦しみ。 その見た目の醜さはひどい。欠陥商品としか言えない。 なぜ、昔のように透明の板式のものが売っていないのか不満である。 あまりに見た目がひどいので、5分もたたず取り外してあきらめる事にした。

    しかし、翌日、そこそこの値段だったので、あきらめきれず、 アクリル板にシートを貼り付ける試みで何度もトライした。 努力の結果気泡が10個ほどまでに少なくなった。

    これを可能にする技術がガムテープである。 シートについた埃を丹念に1つ1つガムテープで除去していく。 気泡が出来たら、シートをはがしガムテープで埃を除去。これの繰り返しで、 なんとか10個までに抑える事に成功した。 アクリル板側の埃をシートに移し、シートの埃をガムテープで取るのである。

    気分転換がしたい時にでも、1つ1つ埃を取っていこうと思う。 最終的には無くなるはずである。

    ただ、何度も付け貼りした関係で、シートのふちの部分が変形してしまった。 その部分の気泡はあきらめるしかない。
2009-01-21
    今までは 8va 記号に限定して、またがり対応していた。 アーティキュレーション記号関連に関しても同様にまたがり対応を行った。

    アーティキュレーション記号は、種類によって、またがるか、そうでないか、 いろいろであるが、どのような記号でも、潜在的にまたがりの性質を持たせた。 記号のメニューから、その能力を引き出すか無効にするか指定できるようにした。 基本的に、アーティキュレーション記号は、またがり無効が初期設定である。

    これにて、アーティキュレーション系の記号もまたがり対応が終わった。 ただ、またがりが無い場合、装飾として動作するものと継続記号として動作するものが存在。 この切り替えは、定義画面で決める事にする。

    ともかく、難関を1つクリアした。 しかし、パートデータの大改造等で、いろいろな細かい動作がOFFになった状態である。 新しいデータ構造で、それらOFFにしてある処理も動作するよう修正しなければならない。

    細かい物は好みであるが、目に見えない細かいものは好きでない。 これからの修正は後者となり、気が遠くなる。 目に見えないような内部的な細かい修正をコツコツしていく必要がある。 それらが全て終われば、エディタ部分が新しい機能が増えつつ、完全に復活する。 まずは、これを行う必要がある。

    それを避けて先に進もうとしたら、ものすごくしょんぼりしてきた。 頭の中で気になってしかたないからである。なので、避けて通れない。 先に、細かい復元が終わらないと、安心して、先に進めない。

    それらが終われば、ドラム譜の設定画面に取り掛かれる。 この画面のために、これだけ、いろいろな修正を行ってきたのである。
2009-01-19
    またがり記号を選択カーソルでずらす仕様であるが解決した。 プログラム側の都合による幅広いイメージでなく、 実際にどう使用するかに着目して仕様を決めると、自然な仕様となる。 直接思考に近いが、どちらかというと現実思考、か、ユーザ思考である。

    また、この時の描画に関しては一時的に若干不自然になるが、機能的に支障がないため、 最終調整の際に検討したい。先に優先すべき開発を進めてしまいたい。

    ともかく、大枠、またがり記号の組み込みが完了した。 次に進みたい。

    いよいよ本番のアーティキュレーションに関してのまたがり対応である。 ユーザが自由に文字を決められるという事は、 またがり記号なのかそうでないのか、またがりかたの違いなどを考慮する必要がある。 またがりの記述もいろいろあるのが厄介なのである。

    これを、ユーザが定義するのか、どのような記号でもまたがりの性質を持たす事ができるのか。 このあたりで、モヤモヤしている。モヤモヤ状態で進めると混乱するといった経験があるため、 何が気に引っかかっているのか突き止めなければならない。 これには時間がかかりそうである。

    モヤを解消する手段として、空想でなく、ひたすら紙に全てのパターンを書いて、 事実を見る作業が有効だと思う。ユーザ思考で実際にどう使用するかを書いていく。 たとえ理論的に可能でも、使う頻度が極めて稀であれば、その仕様の優先は下げて考えていく。 もっとも良く使用する操作を優先して考えていく。
2009-01-17
    パートデータ構造の改善が完了した。 その修正に伴い、エディタ操作、描画、UNDOなどの作り直しも終わった。 データ構造変更により、思いのほか簡単な構造になった事を実感した。 思い切って着手してよかった。これでバージョン7で、この事に関して悩まなくて済む。

    再び、中断していた、またがり記号の開発に戻るとする。 行き詰っていた、またがり記号に伴う改ページ等の処理も簡単に完了。 基本的な、またがり関連は完了した。

    残すは、またがりの細かい部分。1つは、選択記号をカーソルでずらす仕様の対応であるが、 またがり記号の場合、範囲までずれてしまうし、移動によっては、範囲がマイナスになる。 この問題を回避する仕様がなかなか思いつかない。

    更に、またがり記号を選択した時の描画が不自然になる問題も残されている。 機能上は問題ないが、見た目が問題。

    この2つが解決すれば、またがり記号の残りの細かい部分はすんなり進むと思われる。
2009-01-15
    パートデータ構造の改善を行う事を決意した。 はっきりはしないが、今までの構造に不満があったからである。 以前の構造では、いずれクレッシェンドの対応で苦労する。 6.xを完成させてから、また構造を壊して7を作り直すのは、最終的には効率が良くない。 今回やってしまうべきである。結果的に7でやろうとしていた構造にする。

    現在、パートデータ構造の大修正作業を行っているが、 直接思考の発見により、7の試作を行っていた段階よりも、さらに分かりやすい構造にする事ができた。

    確実に、無駄なソースコード量が減っていくのが分かる。 今までの構造はバージョン1から受け継がれてきた構造であるが、 なぜこれほどまでに面倒な構造になっていたのか不思議なくらいである。

    おそらく、長年の楽譜式ソフトの開発の経験によって、 適した構造が分かるようになったのかもしれない。
2009-01-09
    またがり記号の連動処理を開発しているが、 どうにもパートのデータ構造に疑問を感じる。特に改ページの処理が異様に難しくなる。 きめ細かに作りこめば出来なくもないが、バグが潜みやすく、 後のメンテナンスも大変そうである。

    そこで、パートのデータ構造を、やはり変更すべきか検討してみたい。 結局バージョン7でやろうとしていたデータ構造にするべきか検討する事となる。

    6.xとはいえ、結局バージョン7を開発しているのと同等である。 やはり、避けて通れない部分がある。最終形態を目指すとすれば、 いずれ、パートのデータ構造を7にする必要が出てくる。 2度手間になるくらいなら、今回やってしまうべきである。

    バージョン1〜6までのデータ構造のほうが良いか7のほうが良いか。 検討する時が来た。当然時間軸系の記号を対応するには7にするしかないような予感もする。

    今までやってきたことは無駄ではない。全ての考えが生かされているし、 断片的な考えが1つにまとまろうとしているのである。
2009-01-05
    小節またがり記号の描画に成功した。 現在、またがり記号を書き込んで、範囲マーカを動かしたり、 小節やページを追加削除したりした場合の連動処理を開発している。

    またがり記号の連動処理はかなり作業量があり面倒。 UNDOも加えると、かなり細かい。あらゆる操作をした場合でも、 またがり記号の整合が取れなければならない。

    結果的に気が遠くなった。しかし、気が遠くなる原因は脳が付いていけないだけである。 脳は、あまりに多くの関連する事を一気に処理できないようである。

    Aを考えBを考えCを考えるとAがあいまいになっていく。 Aを考えるとBやCがあいまいになる。結果的に全部あいまいになる。 これが、気が遠くなる現象。こうなると、たとえ運良くA,B,C,の開発が100%であったとしても、 脳は不安なので、100%が信じられず、Aを壊したりし始める。

    これを回避するには、紙に書く事である。 現在のプログラムで、どのような操作が実現できたのかを、全て書き出すのである。 たとえば、マーカを次の小節に動かして、次の小節を削除、マーカは前の小節に移動し小節が削除される。 言い換えると、マーカがある小節の削除機能を対応した。という事になる。これで1機能。 こうやって、可能な操作方法を全て書き出す。対応できていない部分が見つかれば対応する。 こうやって、書き出す事で、いずれ、全体の法則性が見つかる。もし、見つかれば、 その法則を満たしているプログラムであるかを検証する。 きちんとプログラムが出来ていれば、他の紙に書いていないパターンも動作する可能性が高くなる。 プログラマが見つけられなかった操作は、バグ報告され、そのとき対応パターンを追加するのである。

    ともかく、またがり記号の開発は大変である。こんな所で足止めされたくないが、 仕方がない。ここはしっかりと取り組みたい。

Since 2000 (C) Studio ftn
http://studio-arts.bglb.jp/studio-ftn/