あらすじ
|
データ構造変更・設計ミス対応後の対処として、ＳＭＦの書き出しを完成させた。
その他、連動処理の開発を主に行った。例えば、画面を切り替えたとき、 リアルタイム処理を一時的に止めてから、データのつなぎ替えを行い、リアルタイム制御を再開する。 といった処理である。これをやらないと突然異常終了を引き起こしたりする。 いわば、安全制御の組み込みである。ユーザには見えない内部的な作りこみとなる。 目に見える部分以外にもソフトウエアの機能はあるので、そういった作りこみを行った。 その他、プリセット関連の最終調整等を始めた。 １０月以降はα版に向けての最終調整作業が主な作業となると思われる。 ＶＳＴごとにドラムマップを保持可能といった機能改善も同時に行う。 ６．０１の価格についても検討をした。これについては案でしかない。 それよりも開発を優先したい。ただ、６．０１は機能的にも大きくなり、 ６．０１から、価格が上がる可能性は高い。ポイントとしては、全て代行販売に切り替え、 代行手数料分の価格が増えるイメージである。これは徐々に移行する。 コメント： 今までは出来るだけ販売価格が同じくらいになるよう調整していたが、 無理のないフェアな価格設定を行いたいと考えた。 シェアウエアはかなりのレベルが求められる事を実感した。 フリー版のように好き勝手に作るといった事はできないし、シェアウエアは機能も求められる。 ユーザが気に入って購入したソフトであるがために、ユーザも的確な要望を出してくる。 初期の価格設定やソフトに関しての考えが甘かったと思う。 その価格では必要な機能を全て含めるのは難しいし、 開発に費やす苦労も、桁違いであると実感した。 サーバのメンテナンス費や運営費、テスト環境やテスト音源、Vista 対応。等々、 今年はかなりの出費であり、将来においても開発資金が必要であると分かった。 良いソフトを完成させるためにも、ゆとりを持たせたい。 そこで、販売価格は代行サイトごとに大きく違っても良いという方針に切り替える。 また、５．４から６．０１の機能分の価格をアップさせる。なんとか手ごろな価格で提供したい。 既にライセンスを持っている方は、無料で６．０１にアップグレードできるので、ご安心ください。 |
2007-09-26 状況
-
プリセットの保存場所や最終調整の仕様が大枠決まり、改良作業を開始した。
ユーザプリセットフォルダと音源設定フォルダの２箇所から、プリセットリストを作成し、 好きなように読み書きできる仕様とした。
通常は現在使用している音源のプリセットが一覧に表示されるが、 画面上の条件を変更すれば、他の音源のプリセットを取り込んだりできるようになる。
プリセットファイルには、各種設定が混在する形式となった。 つまり、１ファイル内にその音源の各種定義を格納する。 音源ごとのファイルになるので、持ち運びが便利になるだろう。
Score Editor に関する共通設定やデフォルト設定は Studio ftn プリセットファイルに格納する。 ドラムマップの初期値などがここに格納される。
一方、音源固有の初期設定は、音源設定フォルダに格納するので、 ユーザがこれを書き換えてしまう事はないし、ユーザのプリセットが混在する事もなくなるので、 配布する時は音源設定フォルダをそのまま配ればよい。
プリセットの分類は現時点で９種類もある。
-
残件が１件増えたが４件対応した。
ついに、残件が残すところ８件となった。ようやく１桁に突入した。
これから、悩み系の問題では、おそらく最後の問題対処を行う。 プリセット全般の見直しとドラムマップの見直しである。
ドラムマップは、ＶＳＴ１つ１つに持つことが可能になるよう調整を行う。 ５．４では、そもそもＭＩＤＩモードのマップをＶＳＴで共有していたので、 不満であった。今回の対処で完全なものとなる。
プリセットに関しては、それをどこに保存しておくべきか？ といった見直しである。開発中６．０１では、音源定義のフォルダに格納するようにしていたが、 ユーザの定義と音源定義が混在するのは、音源定義を配る際に問題となる。 個人的に使っていたドラムマップなどの設定が配られるのは問題である。 しかしながら、音源の初期化用のプリセットは音源定義に含めるべきである。
また、音源定義を使用しない場合、デフォルトでＧＳの設定が読まれる。 個人的なプリセットが知らないうちにＧＳに入ってしまうのもどうかと思う。
さらにＶＳＴに限っては、音源定義すら不要な場合がある。 その場合、フォルダが作られないので、ユーザのプリセットが保存できなくなる。 いったどこに保存するべきか？
更に言えば、ＧＳで作っていたプリセットを他のＧＳ音源に移動したい場合、 音源定義の名前が違うので、プリセットが読み出せない。
こういった問題の最終的な見直しを行う。 これが、終わってしまえば、楽譜ファイルの読み書きの最終見直しを行い、 ＷＡＶＥ書き出しを作成すれば、ほぼα版の完成と言ってよい。
-
不可思議な異常終了に悩まされ続けていた。
処理の見通しが良くなるようあちこちのプログラムを修正していたが、 一向に直らなかったが、ついに直った。
原因は修正している箇所とは全く関係ない場所で思いもよらない原因であった。 予想もしていない部分のメモリが開放されていて、 開放されたメモリをアクセスしていた。 フラグ程度しか参照しないので、開放されていても今まで動作しており、 今まで全く気がつかなかったのである。
たかがフラグのメモリ不具合だけで、これほど不可思議な異常終了の仕方をするのには驚いた。 プログラムを少し変更するだけで、毎回、落ちる場所が変化するので、 こっちの気分も落ちていた。
結局 #if 0 による探索を根気良く行い、問題の箇所を突き止めたのである。
結果的に、全体の処理がかなり洗練されてしまい、 プログラマの思想と実際の処理がほぼ完全に一致する状態になってきた。
長かった道のりであったが、ようやく収束に向かいそうな予感である。 大きな問題がほとんどなくなり、 あとは、残件をつぶしていけばゴールにたどり着くといった状態である。
今までの間に４件の残件を対処した。現在の残件はあと１１件もある。 問題が収束したとは言え、まだ問題が潜んでいるかもしれないので開発には気を抜けない。
ようやく前に進めるとなるとホッとする。
-
楽譜切り替えとモード切替の連動処理を作成している。
リアルタイムでデバイスの起動と停止を操作できるようにしたかったが、 どうも、これのせいで、操作が複雑になり、しかも連動処理の開発で苦戦する事が分かった。 なので、この仕様は後送りにするか、実装しない事にした。 起動停止は設定画面にて１箇所で行う事にしたい。
つまり、切り替え関連は、従来の５．４の仕様に従う事とした。 そのための仕様変更を行っている。かなり操作性がよくなり動作もスムーズになった。 今まで余計な手間がかかってしまったかもしれない。
なぜ６．０１から突然構造が複雑になったのか考えてみたところ、 ５．４では、どうだったのか？と考えた結果、余分な操作性が見つかった。 これで、楽譜切り替えやモード切替時の不要な動作が一気に省け、 しかも、ユーザに想定外の操作をされる事がないので、安全である。 また、それらの安全処理を書かなくて済む。 動作的に従来どおりの動きとなるので、違和感が少なくなる。 もちろん、その仕様でも、６．０１にて複数音源を使用する事ができる。
あと、内部データの状態がどうなっているのか目に見えないので、 デバッグ用の画面を追加した。この画面は開発中しか表示されないが、 これによって、内部データが想定どおりになっているか確かめられるので、 不安になる事無く開発を進められる。
-
楽譜切り替えの連動処理を作成している。
楽譜を切り替えるごとに、デバイスを起動しなおすのは、 やはり、不満が残るため、この部分を改善する事にした。
その結果、新たな制御が必要になり、その組み込みを行っていた。 なんとか組み込みが終わり、全体調整の作業を行っている。 おそらくデバイス関連の最終調整はこれで完了するはずである。
AUDIO と MIDI を共存させようとしたが、 楽譜切り替えで起動停止が動くことがあるため、 やはり、従来どおり、MIDI モードと AUDIO モードを別々にする事になりそうである。 今のところ、同時に使用できて嬉しい事は何もない。 MIDI モードで VST を鍵盤演奏できる。といった点だけである。 これだけのために、起動停止が動作するのは、納得がいかない。 おそらく、多くのユーザは、MIDI モードのみ、もしくは、AUDIO モードのみ。 を通常使用すると思う。
モードを分離することで、起動が遅くなったり無駄なデバイスが動作する事もなくなる。 MIDI しか使用しないのに、ＶＳＴのエフェクター類が動作しても、 ソフトが重くなるだけである。それに MIDI と AUDIO では、演奏タイミングにずれが生じるので、 同時に使用する事はないと考えられる。
-
おそらくみんな普通にそうしていると思われるが、
新たな開発手法を発見した。
それは、ある程度の機能をまとまりに分解し、 それぞれを、デバッグ用メニューに割り当て、 いつでも呼び出せるようにする。
こうすることで、全体の動作で異常が発生した時に、 良く分からなく突然落ちたり、不可解な動きをする。 といった事が少なくなる。
小さな処理を開発者が順を追って命令していける。 これにより、小さな機能が確実に動作することを確認できるし、 確実に完成したという実感が湧く。 さらに、データ構造修正などで、副作用が発生していないか、 いつでも確認できる。
デバッグ機能の組み込みは、安心感と着実感、完成度を高める効果がある事が分かった。 小さな機能の寄せ集めによって大きな動作が完結するような処理で有効だ。 開発中に気が遠くなったり、途方に暮れる事無く、目標を持って確実に前進が可能である。
・・・
最近、Studio ftn での購入関連で疎通が取れないといったユーザが増えている。 Studio ftn のサービスを遠まわしに指摘しているユーザもいるかも知れない。
購入関連で、開発に支障が出ると後々きつい。 そこで、ソフトの販売を全て代行販売にしようか検討している。
その場合、代行手数料が高く付くので、ソフトの価格を上げるしかない。 なんとかソフトを安く提供したく、Studio ftn で直売していたが、 作者はソフト開発に専念すべきかもしれないと考えている。
代行手数料は馬鹿にならない額である。 その手数料はもちろん信頼を示していると思う。 直売分をまかなうには、ソフトの価格がとても高くなるのである。
バージョン６の機能充実と以降の対応も考えれば、 そろそろ価格の変更を検討する時期であると感じている。
これは現時点の案でしかないが、ベクター、AnyWare+ 、が購入先となり、 ベクターは価格が変更できないので、同一価格のまま。 AnyWare+ にて、7000 円 弱でバージョン６を代行販売する計画である。
Classic 版が完成するまでは、ベクターで購入するほうが断然お得という事になる。 ただ、あまりにも価格差があるため、一旦ベクターから登録を解除する事も検討している。 Score Editor の価格としては、7000 円前後となる。
Classic 版のライセンスはずっと使えるので、 既に購入された方はアップグレードをしなくても、バージョン６以降を使用できる。
・・・
そんなことよりも、まずは、開発を優先したい。
-
楽譜の切り替え連動処理を開発している。
２つ以上の楽譜を開いたときに、それらを切り替えた時の処理である。
この時、複数音源なので楽譜ごとに構成が違う。 しかし、ハードウエア音源は、複数存在しえないので、 楽譜を切り替えた際に、音源を停止したり起動したりしなければならない。 また、ＡＵＤＩＯに関してはサンプルレートなどが楽譜ごとに違う場合、 ＡＵＤＩＯに関しても、起動停止を行う必要がある。 また、アサイン中のＶＳＴ音源のサンプルレート変更処理を行わなければならない。
うんざりするような制御であるが、なんとか開発するしかない。 しばらくは、これに時間がかかるため、日記は３日置きくらいの更新となるだろう。
そして、ＶＳＴ音源はハード音源と違い、複数起動できる。 ＶＳＴの場合は、起動停止をしなくて良い。
ここで少々設計ミスが生じる。音源系のデータ構造の保持方法を２つ用意しなければならない。 楽譜ごとに起動するＯＢＪとシステム全体で１つのＯＢＪである。 現在は１つしか分類がないのでＶＳＴの対応ができない。 そのため、保持方法を２つに分類する修正を行わなければならない。
楽譜切り替えの仕様が悩ましく悩み続けた結果このようにする事にした。 ハードウエアの切り替えはそれほど時間がかからないので、 この方法で行く事にした。頻繁に楽譜の切り替えが必要な場合は、 音源一時停止ボタンを付けるしかないかもしれない。
あと、Score Editor が内部で使用するパラメータをプログラム内部に組み込んだ。 これで、ユーザが定義する部分が少なくなった。 ここで思ったのであるが、定義編集画面のリリースは先送りしても良いのではなかろうかと。 テキスト編集で十分である。こうする事でリリースを早める事ができるかもしれない。 しかし、定義編集画面はほとんど完成しているので、リリースしてしまうかもしれない。
ともかく、楽譜の切り替え処理を作ってしまいたい。
-
これからは、あまり余計な事を考えずに前に進む事を主に考えて行動しようと思う。
なので、開発日記を書く暇があるくらいなら、開発を進めようと思う。 日記が更新されなかった日は開発をしていると考えていただきたい。 中間報告はしていきたいと思う。
楽譜保存であるが、まずＶＳＴの状態を保持する処理を作成した。 これを楽譜ファイルに書き込めばＶＳＴの状態が復元できる訳である。
以前の設計ミス対応のための対応を楽譜ファイルにも施す。 しかし、読み込みの際に異常終了した。
１つ問題があった。６．０１からは音源の定義をユーザが書けるようになるのであるが、 Score Editor が内部的に使用する定義も、ファイルとなっている。 その定義を間違えたり、定義が抜けていると、異常終了するのである。
これは、以前からの悩みでもあったが、Score Editor の定義までも、ユーザに託すのは危険である。 なので、Score Editor に関係する定義は、プログラムの中に埋め込もうと思う。 その改良を行いたい。
-
ＡＵＤＩＯパラメータ変更時の連動処理の対応が終わった。残件を１件対処。
しっくりしなかった点であるが、連動処理とは関係なく既に問題が潜んでいた。 それについては対処した。
設計ミス修正に伴う副作用が見つかり、しょんぼり。 それに現在の残件の半分は設計ミス改善のための残件である。
いつになったら完成するのだろうか。 １つ１つの残件が重い。音源が複数になるとこれほどシステムが 込み入ったものになるとは思ってもいなかった。 １件の機能に関しての関連がありすぎるのである。 洗練されてきてはいる。
この込み入りであるが、マルチスレッドに関係する悩みでもある。 基本的にはシングルスレッドで動作するよう設計する。
しかし、非同期的に発生するユーザ操作やＭＩＤＩイベント、 演奏を行うためのタイマやＡＵＤＩＯの処理など、どうしてもマルチスレッド的な処理になる。
つまり、パラメータのアクセスが問題になる。 処理を通過している途中で、パラメータが変更されると誤動作する。 これは、マルチスレッドの常識である。
電車が通過中に線路を切り替えると脱線するのと原理は同じである。 あらかじめ電車を走らないようにし、通過中の電車は駅に到着するのを待ち、 そして線路を切り替える。
線路の切り替えポイントは、ユーザが可能な操作の数だけあるのかもしれない。 １つ１つに脱線しないようなルールを作るのである。 電車が走る事は当たり前なのである。それ以外の作りこみが大変である。 ソフト開発はほとんどが同じだと思う。
ソフトが異常終了するという事は、線路が切れたのに電車が走ってしまったという感じである。 大抵の場合、プログラマは、来るはずのない線路と判断し安全機構を組み込まない。 しかし、想定外の操作をされると、来るはずのないところにやってくる。 来ないようにするか安全装置を付け加える。これがバグ対応である。
線路が円になっていれば簡単である。電車が１台しか走らないのなら簡単である。 しかし、線路が組み合わさり、そこを沢山の電車が自由に走るとなると、 これがなかなかややこしい。複数音源対応はまさにこんな感じかもしれない。
・・・
ひとまず、楽譜保存関連の残件が目に付くので、 それを先に片付けたいと思う。
実は、大きな悩みがあり気がかりである。
複数音源の構成や設定を、楽譜ごとに持つか、システム全体に１つか。 開ける楽譜は複数か１つか。
現在の方向では、楽譜は複数開け、楽譜ごとに音源構成を持つ。 という方針であるが、楽譜を切り替えると音源を落として起動しなおす必要がある。
音源が１つしか使えないのであれば、もともとそれしかないのだから、 システムに１つで良かったのである。 しかし音源が複数になると、こういった仕様の問題も新たに生じるのである。
カット＆ペーストする作業において、毎回音源が起動したり停止したりすると、 さすがに不快である。
これは、楽譜を１枚しか開けなくすれば全て解決できる。 しかし、カット＆ペーストできないのは痛いし、仕様が変わるのは痛い。
構成はシステムに１つ。こうすれば、複数の楽譜を切り替えても起動停止は生じない。 ただ、楽譜を読むたびに、その構成設定をユーザが読み込むのは面倒である。 しかも、過去の楽譜となれば、どの設定を使うか忘れていると思う。 楽譜を読む時にその時の状態が復元されるのが一番良い。
音源機能一時停止ボタンを付ければ良いのだろうか？ これらの仕様決定を行わなければならない。
-
format 0/format1 シーケンサ受け渡し用のＳＭＦ書き出しが完成した。
これにて、ようやく残件が１件完了した。
次は、ＡＵＤＩＯパラメータ変更時の連動処理の対応に入る。 設計を終えて一通り作りこんだが何かしっくり来ない。
１つは、ＶＳＴ音源を再起動しないと設定が反映されないＶＳＴもある模様で、 何かしっくり来ない。ＶＳＴによっては起動が遅いので再起動は苦痛である。 あと、突然異常終了したような気がする。気のせいかもしれないが気になる。 また、ミキサーから登録が外れてしまうのものある。タイミングは不明。
何がしっくり来ないのか調査をしたい。
・・・
ところで、健康対策であるが、塩分の調節をしたら、 ある日の朝、目が覚めたら突然調子が良くなった。 あまりにも体が空気のように軽いので、生きている事を一瞬疑ったくらいだ。 ２０歳くらい若返った感じである。その後塩分を取りすぎて失敗。 突然だるくなった。この事から塩分調節は体調に関係するのではないか？ といった発見があった。
ただ、前日に生大豆(加工食品でないという意味で普通はゆでる)を食べたことによる可能性もある。 大豆は体に良いと聞くが、良くなったためしがない。 これは、加工食品が多いからなのかもしれない。 本当に効くのは生大豆かもしれない。しかしなぜ２０歳くらい若返ったかのような、 体調改善につながった理由は分からない。
引き続き塩分調節を再開したい。 ただ、体調が良くなっても、アイディアがポンポン浮かぶわけでもなさそうだ。 なので、開発がどんどん進むようでもなさそうである。ただ、時間がものすごく長く感じる。
-
設計が終わり、まずは、format 1 標準ＳＭＦの書き出しが完成した。
続いて、format 0/format1 シーケンサ受け渡し用の書き出しを開発する。