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

※ Classic 版のライセンスがあれば今後のバージョンを含め、最購入する事無く全ての Classic 版のバージョンが使用できるようになっています。

2009-12-31 当面は6.xの開発を以下のように行う。

1.設計と開発(プログラミング)を平行して行う。
2.一度に多くの機能を開発せず、可能な限り小さい単位に分けて、 1〜2ヶ月に1回のペースを目指して小出しでバージョンアップリリースする。

〜 今後のリリース予定とそのバージョン番号 〜

6.16 印刷品質の向上と印刷機能追加&音楽記号データ構造改善
6.17 またがり記号化(8va 等の範囲が指定可能になる)
6.18 時間軸機能(クレッシェンド等)予定
6.19 譜表関連機能
6.20 音源設定機能改善
6.21 ピアノ譜&完全複旋律
6.xx 今までいただいたユーザ要望や必要な機能が思いつき次第対応。

※ 開発順は前後する事があります。

  • 6.13〜6.15
    2009-01 02 03 04 05 06 07 08 09 10 11 12

  • 6.11〜6.12
    2008/01 02 03 04 05 06 07 08 09 10 11 12

  • 6.01〜6.10
    2007/01 02 03 04 05 06 07 08 09 10 11 12

  • 〜5.55
    2006/01〜12

  • 今後対応予定の要望一覧


    2010-03-17
      ついに、6.16の機能の全ての設計が完了した。 もちろん新時間軸の設計も音源機能改善の設計も完了した。 あとはひたすら作りこんでいくだけとなった。

      設計自体は実はもっと前に終わっていて、 作りこみ作業のほうを進めていた。

      記号パラメータ関連の作りこみや、 強弱記号の設定画面など、基本的な部分の作りこみが完了している。 この部分が出来たという事は、それほど設計ミスは出てこないと期待できる。

      現在、拍子作成画面を作りこんでいるが、 これがとても大変でこの画面だけで既に1週間くらいかかっている。 今までの拍子作成画面があまりに操作しにくく、だれも使っていないと思われる。 もっと簡単に操作できないかといったユーザ要望もかなり前にいただいていた。

      どうすれば簡単に操作できるか考えに考えようやく実現できそうである。 内部データと操作画面に関しては作りこみが完了した。 あとは、画面からデータを作り出すだけである。 あまりに快適な操作画面になり、感動ものである。

      拍子画面が完成すれば、記号関連の作りこみは大枠完了する。 そうなれば、かなり気が楽になる。 強弱記号の設定画面と拍子画面はそれだけでボリュームがあり、 設計書もメモ的な大雑把なものなので(設計書はかなり前に書いた)、 自分で書いて自分で思い出すのがけっこう大変だった。 拍子記号であるが、プログラミング手順が多いので、 いやいやながら開発していたが、こつこつと進めることで、 案外、けっこうできるものだと、驚いている。

      記号パラメータ画面に関しても設計では見た目が分かりやすくも、 いざ動かしてみると、しっくり来ない点もあり、 かなり試行錯誤し、無事作りこみが終わった。 最終的にデザインも分かりやすくなりDTMらしい感じを匂わせる。

      それと黒画面。右のツリーと融合して新黒画面となる計画で、 長い Score Editor の伝統が新しいものに入れ替わる事となった。 操作性に関してはとても良い感じになっている。

      音源関連もシンプルにまとまり、快適な操作が期待できる。 時間軸機能実現にあたり、かなり多くのパラメータが操作できるようになる。 いかに操作しやすくするか悩みであったが見事解決した。

      とにかくパラメータのつまみが多くなるので、 結果的にDTMらしい画面に仕上がった。これは楽しそうである。

      開発中に時間軸から新時間軸になったため操作が若干変更になるので、 その修正を行った後、音源機能改善に着手予定。 それが終わったら、恐怖の演奏処理の作りこみである。 設計はかなり前に終えているが、これも思い出すのが大変そうだ。 しかも、かなりプログラミング手順が多い。

      演奏までできるようになったら、ファイル読み書き関連を開発後、 印刷機能の作りこみとなる。印刷処理も大改善が行われる。

      このように先はまだ長く気が遠くなるが設計が完了している以上、 こつこつやれば必ず完成する予感である。
    2010-03-06
      新時間軸の設計が大枠完了した。 いくつかもやもやする点が見つかったのでその詳細を決めたら、 時間軸設計は完了である。基本的な考え方は出来たのでこれで行けると見込める。

      新時間軸によって大幅に機能が洗練されかつ多くのことが出来るようになった。 機能が洗練された事で、音源関連の機能までも改良しなければならなくなった。

      今までの予定に更に音源改善を組み込まなければならなくなったのである。 結局、先送りした音源改善が必要になり、ほとんどの内部機能を作り直す事となった。

      時間軸の残りの設計と平行で音源改善をさっさとやってしまう事にした。 操作性がかなり洗練されたため、意外と簡単に修正が終わるかもしれない。

      多くの設計が完了したので、プログラミングの再開を行うと同時に、 平行して印刷機能の設計を再開した。

      これからもっと忙しくなる。日記など書いている時間もないので、 手短に報告を済ませたい。かなりの開発ボリュームとなってしまった。 もうこれは避けられないのである。 そして、毎年のパターンだ。結局ボリュームが大きく手に負えず断念するパターンとそっくりである。

      しかし、今までと違う点が1つある。 それは設計をしっかり行った事と設計が完了しているという点である。

      詳細スケジュールのほうも見直し、開発準備は整った。 不安を出来る限り少なくするべくどんどんプログラミングを進めたい。 問題が早く見つかれば早い段階で見直せる。
    2010-02-27
      本日DTMに関して作者があれこれ語るBBS2のほうは完全に閉鎖した。 Score Editor 完成後に、作曲に関する活動を再開したいと思う。 作曲活動の再開にあたってはBBS形式でなく 役に立つ情報をまとめたホームページの記事をアップする形式を予定している。

      これから Score Editor の開発に徹する事になるが、 いくつか進展があったので報告したい。

      音源ごとに音源エンジンと再生エンジンを作成するという話であるが、 考えに考えた結果、そのような事をしなくても、 いろいろな音源で演奏できる方法が思いついた。 これによりパソコン用音源やピーターのVST音源も含め 6.16の段階でコントロールできるようになるかもしれない。

      よくぞここまで仕様が辿り着いた。といった感じである。 Score Editor 1.0 の頃からなんとなく時間軸機能のイメージは、 ぼんやりであるが存在した。しかし、具体的に実装しようとすると、 さまざまな要素の問題によってどうしても実現不可能であった。

      それは3.0、5.0、6.0、の各、開発前に実現しようと開発しては、 時間軸機能は実用的にならず、妥協してそれ以外の機能を追加したバージョンとして、 リリースが続けられた。こうして時間軸機能が備わらないまま現在に至っている。 しかし、その間も、内部的には時間軸機能の試みが進化を続けていた。

      ようやく6.15にてパートデータ構造が最終形態に近くなるにつて、 6.16にて記号データ改善を行う予定で進めていた。 記号データ改善により、下積みの準備が全て整うのである。

      ところが、記号改善の際に、多くを作り直さなければならなくなった。 その際に、印刷をはじめ、さまざまな、内部機能が見直され、 従来の機能に関してのパラメータ機能だけは、 時間軸対応したものを6.16とする方針になった。

      これは、ヤブリンスキー方式による入力があまりに大変そうだと感じたからだ。 せめて、もっと楽に入力できれば。という思いで時間軸の限定機能の設計を始めた。

      現在、その設計は終えており開発も時間軸機能の画面操作は90%完了している。 そして最後の最後の設計の詰めが必要となった。

      その10%の部分がとてつもなく大変なのだ。 音源と記号と演奏とパラメータ、これらが密接に関連している関係で、 これらの仕様が完全にならないと、開発の続行ができなくなった。

      今までもずっとそうだった。最後の最後で実現困難な状況になる。 しかし、今回は妥協しても、何も別の機能を付けられない。 今までの開発経験を駆使して、地道に設計を続けていた。

      そして、音源ごとに機能を別にする。という発想で妥協しようとした。 そこで、パソコン音源という簡単な音源用のエンジンを前提に設計を始めた、 この時、ショッキングな事実を知ってしまったのである。

      どんな優れた音源でも、MIDI音源では完全な奏法は実現できない。 というものである。MIDI音源は鍵盤奏者のために設計された MIDI鍵盤演奏規格でしかない。というショッキングな発見。 つまり、MIDI 規格はバイオリン奏法が可能なようには 設計されていないのである。所詮鍵盤演奏のための規格なのである。

      もし、それができないなら、現状の6.15程度の表現しかできない。 頭の中が真っ白になった。

      DTMのMIDI規格は全然ダメではないか! そうでなく、こういう風になってればよかったのになぁ。 と思いながら、そのままショックで寝込んでしまった。

      MIDI規格上でそういう風にできる方法はないか思い当たるCTRが1つある事には気が付いていたが、 それはパソコン音源には到底対応されていなそうだし、 VSTでも対応されていないだろう。GSで唯一対応されているが、 それでも、作者の考えるようには完全にはできないというのは、 調べなくてもすぐにわかった。

      そのとき、思ったのだ。こういう風になっていれば。 これぞ、問題の本質そのものだったのだ。 MIDI 規格がそうなっていないから、今までどうしてもできなかったのだ。 ようやく、問題がはっきりと認識できた。

      そういう風になっていなければ、そういう風にすれば良いではないか。 そういう風にする事が作者のやるべき事だったのだ。 そういう風にしなければ時間軸機能は実現できないのだ。

      ひとまずざっくりといろいろな音源を考慮し、 仕様を考え、さらに別の概念を取り込む事で、 ようやく、全ての問題が解決されようとしている。

      よくぞここまで辿り着いた。という感じだ。 昔からずっとこれが欲しかったのだ。 いままでずっともやもやしてつかめなかったものがついに目に見える形となる。 振り返ってみると当初考えていた構想とは大幅に違うものが真実だったことも明確になる。

      これを実現するにはさらに常識はずれな機能を加えなければ実用的にならないが、 実験を行った所、無事その問題も回避できた。

      もし、この概念を知ったらみんなショックを受け、 MIDI音源の仕組みが変わってしまうかもしれない・・・。 音楽を演奏するという事はこういうことだったのである。 確かにその考えのとおりだ。といった感じだ。

      これとかそれとか、に関しては、現時点では仮説の段階で、 仕様をもっと詳細に詰め設計を完成させなければ、確かな事は言えない。 そのため、作者の空想であてにならないでたらめかもしれない。

      しかし、根本としての考えは確実なものであるという実感がすごくある。 あとは設計を続け明確にし実際にプログラミングし動作を確かめるだけである。

      もし、うまくいけば、それが6.16となるかもしれない。 逆にうまくいかなければ、深刻な状況になる。 その時は入力法の改善と印刷機能をリリースする事になる。



      時間軸機能の設計が続いているが、平行して進めていたプログラミングのほうは、 設計を終えた部分に関して完了している。 そのため、プログラミングは中止し、設計だけの開発が実は続いている。

      その間に平行してフォントの作成を地道に行っていたが、 やっと全てのフォントが完成した。美しさの調整はまだだが、 フォントに関して全ての準備は整った。 これを描画するためのプログラミングを時間軸の設計と平行して進める。
    2010-02-24
      ようやく風邪のほうが完治した。 しかし、新しい風邪がまたやってきてやられそうだ。

      本日BBS2のほうは大枠目的を達したため閉鎖した。 BBS2の閉鎖は2、3、日後を予定していたが、 待っている事もないので本日閉鎖する事にした。 リンクを外しただけなので bbs2/bbs.cgi にアクセスすれば、 現在でも見る事ができる。いずれ完全に削除される。

      BBS2にも書いたが、作者は文字を書くのに時間がかかり1回の書き込みに2〜3時間かかる。 この時間を Score Editor の開発にまわしたいという思いがあり、 BBS2を閉鎖した。この掲示板があると、どうも、あれこれ気になって、 開発に集中できないような気がしたし、回りを振り回してしまうような気もしたので、 一旦閉鎖し開発に集中する事にした。

      今作者がやらなければならないのは6.16の開発ただ1つである。 また、今後も6.17、18、その後も集中作業が続くと見込まれ、 それに徹しなければならないと思った。

      これらの開発が終わったらBBS2の代わりに、 ためになるホームページの記事を書いて公開していこうと思う。 BBS2で書いていた頭の中の途中の空想でなく、 きちんとまとまった形で公開する事にしたい。

      内容としては、作曲、VST、Score Editor の活用法、音源研究、などを計画している。 それには、まず Score Editor を完成させなければならない。

      Studio ftn はソフトの開発と公開を行うサイトなので、 本来の姿に戻ったという訳である。 ユーザが求めるものは、作者の独り言や独自理論でなく、 ソフトウエアそのものだと思う。

      開発日記のほうはそのまま続くので、 作者の声や文句?は引き続きこの場で見る事ができる。

      開発状況であるが、これがまた、設計最後の詰めで、 困った事が起こっている。音源互換性の問題である。 あらゆる音源を動作させようとするとどうしても仕様が煩雑かつ、 平坦になり、難しい操作をしないとユーザは使えなくなる。

      一歩間違えば6.01の時の状況になる。 機能があっても難しくて使えないため、機能がないのと同じ事。 になってしまう。

      この状況を防ぐためには、壮大な企画を始めなければならないかもしれない。 音源エンジンと演奏エンジンを、音源ごとに開発するというものである。

      たとえば、ピーターCOMPLETE用の演奏再生エンジンを別途作ったり、 MIROSLAV用演奏再生エンジンを作るなどである。

      手始めにパソコン音源用演奏再生エンジンを作り、 それを6.16とする方針になるかもしれない。

      次に、D70用(Roland SC系)エンジン。次に MIROSLAV といったような計画をしている。 VST音源を使用している人には待たせてしまい申し訳ないが、 その間はMIDI機能を代用して使用できるので現在と同じ状況として、 使用可能である。

      あくまで、この専用エンジンは、高度な演奏を実現したい場合だけに、 必要となるものである。

      これが実現すると、めんどうな設定は一切不要で、 いきなりその音源をフルに使えるようになる。

      まずは、万能な規格であるGM,GSをターゲットにする。 多くの音源はこの規格を基本としているので、 今までできたことが出来なくなる。という事はない。

      逆に、今までできなかった、複数のドラムマップ(ドラムの音色を1つ1つ作る)やバリエーションエフェクトが 使えるようになったりする。これはGSに特化した画面やエンジンを設計する事で可能になる。

      プリセットを読むだけで適切な設定がされ、 その定義はこちらで全て用意するので、ユーザは普通に使うだけで、 その音源の性能をフル活用できるのである。

      たとえば、GSによる、複数のバイオリン奏法のシミュレーション、 などを、こちらで完全プログラミングしてしまう。 ユーザは音楽記号とパラメータを使うだけで、その奏法が再現される。

      この壮大な開発に取り組むため、BBS2で遊んでられないと見込んだのである。
    2010-02-16
      のどがやられているが、風邪としての症状はなくなりつつある。

      開発のほうは通常通り行っても大丈夫になったが、 ヒエがこたえる。体調管理において油断はならない。

      その間も開発は地道に少しづつであるが確実に進んでいる。

      時間軸機能の画面操作のほうが90%完成。 前回と進行状況は変わらないが、ドラム関連の操作に関して使いにくさを感じたので、 その仕様を新たに設計しそれを組み込んでいる。 もう時期時間軸関連は完成する予感である。

      更に、平行して進めていた演奏処理の設計であるが、 音楽記号系の設計が完了した。続いて時間軸系の演奏処理の設計を始めた所である。

      今回の演奏処理設計にて、ついに、トリルの演奏が自動になる。 今までのトリルは自分でパラメータ適切に指定するという仮の仕様だった。 これが楽譜の記譜どおりに演奏できるようになる。

      前打音。今回は複前打音も考慮して設計した。 旗の結合までは今回はやらないが、複前打の演奏は可能になるかもしれない。 これを実現するにあたり、最終的に通常の音符側の仕様も追加となった。

      音符単位で強弱とゲート補正が設定でき、更に時刻補正ができるようになる。 これにより、微妙に演奏タイミングをずらす等が可能になる。 また、ペダル記号に関してもこの考慮(設計)を行っている。

      実現が難しければ、次のバージョンへ妥協するかもしれないが、 現時点ではなんとかなりそうだと思っている。

      こうして時間軸機能と演奏機能が着実に完成しようとしている。

      記号の最終的な詰めがまだなので、それらの設計が全て終われば、 時間軸系の開発はほとんど終わる。

      6.16はそれだけでなく、フォント改善と印刷機能追加を行う。 印刷機能に関して設計は10%くらいしか進んでいないため、 これが全て終われば、6.16の山は頂点に達する。

      確か12月くらいに開発を始めた6.16であるが、 2ヶ月ちょっとかかっている。時間軸までで3ヶ月とすれば、 全体で6ヶ月の開発期間を要するボリュームという感じである。 6.16のリリースは6月くらいになるのではないかと思われる。

      これで Classic 版の山に達すると考えれば、あと少し。 実際は6.18までできて Classic 版の山を越える。 もちろん、音源機能の改善も行わなければならないので、 今年中は Classic 版の開発で苦しむだろうが、 長かった苦しみももう時期終わるのかもしれない。

      ちなみに、拍子画面に関しても今回改善を行う事になっていて、 設計が終わっている。n/n 指定で簡単に拍子指定ができるようにしてほしい。 という要望をかなり前にいただいていたが、6.16でそれが実現される。 新たに設計した拍子画面はかなり操作性が良く分かりやすい。
    2010-02-09
      冬の不調期。プログラミング脳は通常に戻ったようだが、 体調に関して不調が続く。 万全な体調管理にも関わらず、ノロ風邪やのど風邪など次々に感染した。 そして現在のど風邪でダウン中。何年かぶりののど風邪である。

      のどかぜ程度で休息を取るのか?普通は取らない。 しかし、だらだらしてても無駄に脳が消耗するだけというのは、 長年のプログラミング経験で体験している。 まずは体調を整える事に集中したほうが全体的にはスムーズになる。

      その間も、1日につき1〜2時間くらいだけコツコツ開発を続けていて、 進みは遅いが確実に開発が進んでいる。 休息するにしてもあまりに退屈なので、 毎日、ちょっとだけ開発に手をつけてしまう感じで進んでいる。

      そしてやっとの事で、時間軸系のデータ処理関連の開発が90%完成した。 90%とは言うものの、核となる部分は無事開発を終えた。 この部分はクレッシェンド対応版6.18でもそのまま動作できる構造となっている。 6.16では音符の強弱などの操作のみ先行リリースし6.18でクレッシェンド等が対応される。

      6.16でクレッシェンドが対応できないのは、 記号の作りこみと演奏処理の設計を6.18で行う事にしているからである。 できるだけ早く音符強弱操作を提供すべく、このように段階的リリースを計画した。

      基礎部分を確実に安定させてからクレッシェンド記号を対応する。 クレッシェンドが難しいのは、小節をまたがる記号の実現が、 Score Editor の場合、画面操作と描画と印刷に関してが特に難しいからである。

      6.16リリースまでの残件は以下のとおり。

      1.時間軸機能(残り10%)
      2.記号関連
      3.フォント関連
      4.楽譜関連
      5.演奏処理
      6.印刷機能
      7.ファイル読み書き
      8.最終調整

      ようやく1.が完了しようとしているが、まだまだ先が長い。 平行して進めている超詳細設計のほうは5.の演奏処理を行っている。 それが終わったら2.3.4.6.7.の超詳細設計を進める。 画面操作系の設計は印刷を除いて1.〜8.まで全て終わっている。

      6.16の本質は記号データ改善版となっていて、 それに関連して、上記の修正がどうしても必要で、 今回は開発ボリュームがとても大きい。しかし6.16を無事リリースできれば、 その先はずいぶん楽になってくる。 6.16は Score Editor Classic の山場と言える。
    2010-02-02
      あれから、思ったより沢山開発が進む。 ミスもなく思い通りにプログラムが動作してくれた。

      しかし本日。またしても不調に。 まず、体温が低下ぎみ。妙に冷え込む。 そして、腹痛系の風邪をひく。 治しても治しても、次から次に新しい風邪がやってくる。 いったい世の中どうしたというのだろう。 去年の2月くらいからシツコイ風邪に悩まされる。 それはいろいろに変異し、何度も襲い掛かる。

      後に話題になったインフルであるが、もっと前から流行しているのである。 気が付いて騒がれるのはたいてい後になってからだ。

      例のたべものに頼ってみたが、さすがに風邪となれば無理のようだ。 やる気はあるしプログラムで悩んでる訳でもない。 単に、体調が良くないのだ。腹痛の連続だ。

      開発のほうは問題なく進んだ。 本当はもっと進める予定であったが、肩の力が抜けると思っているうちに、 腹痛が再びやってきたため、効率が良くないと判断。

      仕方なくここは眠りに付くことにしたい。 どうやら作者は冷え込みに弱いようだ。これが冬の不調期の原因のような気がする。
    2010-01-31
      不調期を克服。

      とある食べ物を食べると ftn の性能はアップする。 その食べ物とは、とある一般的なインスタント食品である。

      今まで、これを食べてうまく行かないことはなかった。 今回ばかりはそれに頼った。これは健康に良くないので、 ここぞというときしか頼れない。

      不思議が生じた。気が付くと、設計書を書き始めていた。 驚いた事に、その設計書には手順がなく沢山の図だけで描かれている。 詳細なプログラム設計書といえば、手順を細かく書いたものだ。 しかし、今回作成した設計書は図だけが並べてあり、 赤と緑などのカラフルな色分けがされた設計図なのである。

      しかし、これでうまくいくはず。という実感があった。 早速コンピュータに入力してみる。 つまり、図からプログラムコードの変換を行う。 なんとミスが1回あったが1発で動作してしまった。 ある食べ物を食べてから、この間2時間である。

      1週間くらい悩みがんばってもできなかった事がたった2時間でできてしまった。

      とうとう冬の不調期を乗り越えた。 しかし、たった1時間のプログラミングの後はぐったり状態だった。

      やっぱりそうだったのである。 冬の ftn は芸術脳に切り替わってしまうのだ。 プログラミング脳は完全に停止する。

      つまり、右脳を刺激するような完全に絵のような設計図を描きさえすれば、 それをプログラムに変換する能力を持っている事に初めて気が付いた。

      なぜ手順が書かれていない図形からプログラムが書けるのか。 これは作者の隠れた特技なのかもしれない。

      ちなみに、時間軸の小節追加処理。に関してできた。 今度は時間軸小節削除をこれから開発する。設計図はやはりカラフルな図形になるだろう。 またしてもうまく行けば、冬の不調期克服かもしれない。
    2010-01-30
      とうとう作者の不調期がやってきた。

      プログラムレベルの詳細な設計は時間軸関連の部分に関しては完了。 その設計を確認しながらにしても、なぜかプログラミングが進まない。

      頭がまったく回らないのである。 どんなにもがこうとも、まったく進まない。 仕方なく、プログラムレベルよりも更に詳しい設計をする事にしたのである。

      現在、その設計をやっている。この設計書はプログラムそのものであるが、 更に絵や図を入れ込んだ設計書になっていて、これで作れなかったら馬鹿。 というレベルまで設計書を作成。

      で、それでも作れない!。信じがたい状況なのだ。 ほかの事は頭が回るのだが、プログラミング。というより、 コーディング。の脳が全く動かない。

      そして、体調不良。とにかく体が芯から冷え込むのである。 じゃっかん気分も悪い感じだ。おまけに、風邪が移ったものの、 心地よく風邪が常駐してしまって、ジワジワと体力を奪われる。 肩から力が抜け、全体的にまったく力が入らない。

      仕方なく休憩するものの夜になると元気になるが、 夜なのでプログラミングは出来ない。 夜に活動すると精神に異常をきたした経験があるので、仕方なく断念。

      この現象に関して、自己分析も行った。 おそらく、あれこれ気になって仕方ない時期なのかもしれない。 気が散る。というやつである。 仕方なく、BBS2で、吐き出しているものの、 まだ、落ち着かない。

      開発日記の更新をしていなかったので、それを行うべく、 こうして過去ログを整備した。 バージョンごとでなく、日付ごとにしたほうが分かりやすいので、 今回からそのようにログをまとめた。

      プログラミング脳は全く動作しないが、 いちお、超詳細設計のほうが微弱にだが進んでいるので、 引き続きそれを行いたい。

      いっそのこと、調子が良くなってから一気にやったほうが、 案外良いのだろうか?心の声を聞く限り、プログラミングは無理。 と言っている。1年間連続運転というのは無理なのかもしれない。

      だからと言って、休憩するにしても、これがこれで落ち着かない。 いったいどうすれば・・・・。といった状況だ。 この不調期は確定申告を終えると改善される事が多い。 これが終わると、春が来た。という感じになる。
    2010-01-20
      音楽記号とアルファベット等のフォントの作成が全て完了した。 手書き作業とフォントエディタを使ったデータ作成は 思いのほか右手にダメージを与えたようだ。再び手の痛みがひどくなってきた。 手が痛いながら最後の力を振り絞ってフォント作業を行った。 プログラマにとってこのような美術的作業はかなりの苦痛でもあったが、 ひとまずデータ化が全て終わったのでほっとした。

      フォント作成はまだやるべき工程がある。 現時点で紙に書いた手書きのフォントをコンピュータ上でデータ化する所までが完了した。 この段階では形状が大雑把なので最終的な微調整をする作業がまだ残っている。 アルファベットの線の太さを全て統一したりより大きく拡大して曲線を美しくするなどの作業がある。 全体バランス調整を行う訳である。更にプログラムで制御するための付加情報の作成もしなければならない。 デザインに関しては、中でもペダルセンツァ記号だけが難しい。しずくが飛び散ったような記号であるが、 幾何学的かつ均等間隔で角度の違う同一の形状が組み合わさっており、 正確に手調整をするのは難しい。音楽記号で一番難しいのがこの記号となる。 回転体機能をフォントエディタに追加する必要がありそうだ。

      一方、平行して進めていた時間軸機能の詳細設計がもう少しで完了する。 設計が完了したらひとまずフォント作業を中断し時間軸機能の開発を再開する。 音楽記号や演奏処理、印刷機能などの詳細な設計を平行して行う。 プログラミングが追いついたら、フォント関連に戻ろうと思う。

      空き時間が一切無い無駄の無い開発が進んでいる。
    2010-01-16
      詳細な設計をして良かった。

      設計をする事で、よりシンプルで分かりやすい内部構造が思いついたのである。 この構造が思いつく前では、複雑で分かりにくくしかも処理速度が遅い。 といった問題に悩まされていた。何かおかしいと思いつつも進めたが、 まるで生きているようにいう事の聞かないプログラムになり、 最終的には無限に発生するバグにより、これは変だという事を予感し、 詳細な設計をする方針に切り替えたのである。

      設計してみて良かった。構造が簡単になるばかりでなく処理速度も理論上100倍向上した。 それでも速度が心配だが、1000小節以下の曲であれば快適に動作すると予想している。 おかしいときは本当におかしい。すぐにプログラミングをやめて設計をする。 やっぱり、これは正しかった。

      コンピュータから離れる事で気持ちにゆとりができるのも不思議だ。

      ただ、完全に設計だけになると、一度にたくさん出来ないので、 空き時間が出来てしまう。そこで、フォント作成の作業と設計を平行して行う事にした。

      フォントの作成であるが、ようやく記号や文字の下絵が全て完了した。 下絵は、紙に鉛筆で書く手法で行った。 アルファベットだけでも何種類も必要で、OSのフォントに頼ろうかとも思っていたが、 OSによって見た目が変わるのがイヤだし、音楽らしい雰囲気を高めるために、 結局、アルファベットのフォントもデザインする至った。 音楽で使われるフォントは大枠 roman 系と sans 系である。 sans 系はコードネームで必要となる。roman 系にもいろいろあるが、 いろいろな印刷物を参考にした結果、old style に行き着いた。 実はピアノ譜では他の書体も使うが、z の形に違和感があったため、 old style に統一する事にした。書体は時間軸機能が完成した後に増やして行こうと思う。

      本日から、鉛筆で書いた下絵を取り込みベクターフォントを作成する作業に入った。 まずは大雑把な原型を作成する作業を行い、最終調整を行う。 原型の作成であるが、意外と sans 系のような直線を主としたフォントの作成が、 とても難しかった。曲線を主とする roman 系のほうが楽である。 sans フォントは幾何学的?ということもあり、形がずれていると綺麗にならない。 線の太さも均一なため、調整がとても大変で、0〜9まで作成しただけでぐったりだ。

      フォント作成だけでもけっこう時間がかかりそうな実感を得た。 設計と平行して作業をするのに適しているようだ。これにより全体の作業効率が上がる。

      詳細な設計の話に戻るが、ほとんどプログラムレベルの設計でもあるが、 設計と言いつつこれは、プログラムを作っているのと同じ事である。 紙の上でやるかコンピュータ上でやるかの違いであるが、 紙の上でやったほうが、効率が良いという不思議な体験をした。 実質、プログラミングが進んでいるのと同等と考えても良いかもしれない。 詳細な設計を終えたあとは、コンピュータに書き写して行く程度なので、 プログラミングは簡単に終わると思われる。 つまり、詳細な設計に時間をかける価値が十分にあるという事を認識した。
    2010-01-13
      6.16 の作業項目の全体が明確になり、 開発ボリュームが明確化された。

      作るものにもよるが、画面設計や操作方法と概要の設計が終われば、 調子の良いときであれば、いきなりプログラミングできる。

      しかし、今回ばかりは、詳細な設計が必要であると認識した。 6.16は新機能が盛りだくさんである。 新しい機能ゆえ今までの経験だけでプログラミングすると、 循環ループに陥りやすく効率が低下してきたのを感じた。

      出来るところはプログラミングを行い平行して印刷機能などの設計を行っていたが、 本日からプログラミングを一旦止めて、詳細な設計を開始した。 設計は1ヶ月くらいかかると思われる。プログラミングも1〜2ヶ月くらいだろうと思われる。

      これまで行った開発で問題点なども把握する事ができたので、 問題解決も含んだ形の詳細設計を行う。プログラミングレベルまでの細かい設計となる。 時間軸機能や印刷機能は、そこまでの設計をやらないとならないようだ。

      ちなみに作者は1〜3月の期間はどうもプログラミングの調子が良くない。 これは毎年の事である。この期間は紙の上の設計を重視し、 コンピュータから離れたほうが良いのかもしれない。 もし、この作戦がうまく行けば、冬の不調期という壁を克服する事になる。

      一方、この時期はなぜか作曲などの芸術活動の才能を発揮するようだ。 思い浮かんだ曲を試しに書きとめたのだが、かなり良い感じの曲が出来た。 しかし、遊んでいる場合でないので、曲作りは断念した。 今回ばかりは、開発の事だけを考えたい。去年のあらゆる開発経験を活かして、 6.16に取り組んでみたい。
    2010-01-06
      時間軸機能の初期版を開発中である。これを実現するにあたり大きな壁は越えることができたが、 連動関連の処理が必要でこまごまとした開発が続いている。 時間軸機能を作り操作し、操作性に関していろいろ悩み試行錯誤の結果、 やっと、快適に操作できる仕様になった。違和感の無い見た目と操作。 これが時間軸の課題でもあったが、この作業が完了すると精神的な重荷が減る。

      演奏処理以外の山は越えた。印刷機能の設計も、大きな壁があったが、 これも無事設計する事ができた。印刷に関しては更に詳細な設計を引き続き行う。

      大きな山は越えつつあるが、一向に完成に近づいている感覚がない。 それは、細かな調整がかなり多いからかもしれない。 そういった細かい部分を全て完成させないと、全体的に完成しない。

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