http://judstyle.jp/wiki/JWU.exe
JWU.exeをV2.20にバージョンアップ。
もちろんLo-fi機能はコミケ用ww
Lo-fiといっても、積分ロジックはともかくとしてLPFは搭載していない、このジャリジャリした感覚のLo-Fiが個人的にはかなり使い物になる・・・・はず。というか昔はよく使った。
画像出力機能は、まあ・・・おまけみたいなもんだけど、迂闊に適当なWAVを突っ込むと横幅数百万ピクセルのイカれたBitmapファイルが出力されるし、これをWindows標準搭載のMSPAINT.exeで開いちゃうと、かなり切なくなること請け合いだ。
マニュアルは書く暇がないのでコミケ終わったら書くか。
というか、あれこれペンディングしている事柄が多すぎる・・・。
2008年12月19日
2008年10月22日
PMDMX(8)
すっかり忘れてたが、MCMX1.exeのVer.1.31をリリースしておきながら、マニュアルにも履歴にもその部分の追記するのを忘れてた。何ヶ月か放置していたが、完全に記憶から消える前に記述しておかないとなあ・・・・
というわけで、V1.31の仕様を取り込んでドキュメントを更新しておいた。配布しているモジュール自体の変更はないけど、今日やらないと多分また1ヶ月くらい放置してしまいそうだからなあ。
http://judstyle.jp/wiki/MCMX1.exe ←.exeで終わってるけどHTMLです
http://judstyle.jp/wiki/MCMX1.exe/history
というわけで仕様の確認をしていたのだけど、
・MCMX1.exeがMML2本に対応し、PMDMX0.exe 4モジュール分に対応
・それに対応したMML解釈がいくつか
だった。
http://www.liarsoft.org/diary/20081012.html
10/12分 - 正直日記
で指摘されているのだが、確かにテンポ変更はMMLの各モジュールに配置しないと反映されない。これは、演奏中にテンポを変えるという発想が俺にはnothingだからまったくその通り。自分でMMLを書くときも、タイマー変更(T/t)や小節長さ変更(Z)は使っていない#FM3Extendパートに記述する癖があるので、各MMLのNnパートにテンポやらZenlenを記述するようにすればいい、というかそうするしかない。
というわけで、今のバージョンはPMD純正のMC.EXEに頼っているからこれ以上の改造は難しいので、MCMX次期バージョンを策定中。PMDのMMLに依存している現状では、これ以上の効率化はムリかな、機能を追加すればするだけ複雑になっていくような気がする。
基本コンセプトとしては、「使用頻度が低いわりに単文字で動作するMMLを極力排除して、大文字は全て単文字マクロにする」ということを意識していたりする。有体に言うと、NAGDRVとかそこらへんの発想だね。いわゆるマクロとしては、英大文字26種の単文字マクロ、感嘆符付き英数文字62種の変数、疑問符付き文字列・・・という3カテゴリを用意した。文字の割付は概ね完了。
MML設計に興味がある奇特な人専用→MCMXII-20081020.zip(MS/Excel2000)
で、性能検証はあんまり進んでないんだけど・・・実用的なモジュール数は4個まで。MCMX1.exeで1回でコンパイルでき、PMDMX0.exeの表示が崩れない限界。性能面では、Pentium4/3GHzで16モジュールくらいまではなんとかリアルタイム発音ができる。メモリよりもCPUパワーとI/Oウェイトが限界。まあ、俺のVAIOノート(Pentium2/400MHz)でPMDWin.dll 2モジュールくらいまで扱えれば問題にはならないと思ってるので、現状では性能面を気にしてはいない。
Core2Quad/3GHz台だとどれくらいのモジュールを動かせるのか興味はあるが、何十音も同時に発生したって俺の耳では検証できないので諦めることにするよwww
というわけで、V1.31の仕様を取り込んでドキュメントを更新しておいた。配布しているモジュール自体の変更はないけど、今日やらないと多分また1ヶ月くらい放置してしまいそうだからなあ。
http://judstyle.jp/wiki/MCMX1.exe ←.exeで終わってるけどHTMLです
http://judstyle.jp/wiki/MCMX1.exe/history
というわけで仕様の確認をしていたのだけど、
・MCMX1.exeがMML2本に対応し、PMDMX0.exe 4モジュール分に対応
・それに対応したMML解釈がいくつか
だった。
http://www.liarsoft.org/diary/20081012.html
10/12分 - 正直日記
で指摘されているのだが、確かにテンポ変更はMMLの各モジュールに配置しないと反映されない。これは、演奏中にテンポを変えるという発想が俺にはnothingだからまったくその通り。自分でMMLを書くときも、タイマー変更(T/t)や小節長さ変更(Z)は使っていない#FM3Extendパートに記述する癖があるので、各MMLのNnパートにテンポやらZenlenを記述するようにすればいい、というかそうするしかない。
というわけで、今のバージョンはPMD純正のMC.EXEに頼っているからこれ以上の改造は難しいので、MCMX次期バージョンを策定中。PMDのMMLに依存している現状では、これ以上の効率化はムリかな、機能を追加すればするだけ複雑になっていくような気がする。
基本コンセプトとしては、「使用頻度が低いわりに単文字で動作するMMLを極力排除して、大文字は全て単文字マクロにする」ということを意識していたりする。有体に言うと、NAGDRVとかそこらへんの発想だね。いわゆるマクロとしては、英大文字26種の単文字マクロ、感嘆符付き英数文字62種の変数、疑問符付き文字列・・・という3カテゴリを用意した。文字の割付は概ね完了。
MML設計に興味がある奇特な人専用→MCMXII-20081020.zip(MS/Excel2000)
で、性能検証はあんまり進んでないんだけど・・・実用的なモジュール数は4個まで。MCMX1.exeで1回でコンパイルでき、PMDMX0.exeの表示が崩れない限界。性能面では、Pentium4/3GHzで16モジュールくらいまではなんとかリアルタイム発音ができる。メモリよりもCPUパワーとI/Oウェイトが限界。まあ、俺のVAIOノート(Pentium2/400MHz)でPMDWin.dll 2モジュールくらいまで扱えれば問題にはならないと思ってるので、現状では性能面を気にしてはいない。
Core2Quad/3GHz台だとどれくらいのモジュールを動かせるのか興味はあるが、何十音も同時に発生したって俺の耳では検証できないので諦めることにするよwww
2008年07月15日
PMDMX(7)
PMD関連のドキュメントを整理。
・・・・今更先週末の話だw
で、最近PMDMXを使ってFM24音など使ってみたものの、久しぶりな上に2本のMMLを同期しなきゃならんので、いろいろと普段使わないMML命令を使うことになる。が、PMDMML.MANが8カラムtabテキストなのでちょっと困った。うーん。
ということで、秀丸マクロでPMDMML.MANをHTML化などしてみたわけだ。例によって、作業時間は仕事場での昼休みを割り当てて、コミケ作業に影響が出ないようにはしている(が、コミケ作業は遅れている。もはや遅れるのが予定調和というのも情けない話だが)。
久しぶりに秀丸マクロを組んだが、これはMMLにも当然応用できるわけだが、今までほとんどやったことがないなあ。なんでだろう、便利なのは判るんだが、カタルシスに欠けるというか、直感をロジックに置き換えるの頭がないのか、そんな感じか。
で、そのまま仕事場での昼休みは終わり、本業用のツールを作っている最中に「あれ? このロジックは昔組んだことがある」とPMDRC.dllのソースを引っ張り出したら、なんと4年越しのバグを発見ww
今直すヒマなんてないがメモっておく。
・局所ループ内の最後で転調すると、ループ終了記号と前後逆になる
・相対転調と絶対転調の内部処理が交錯していて正しい値が出ない
この辺はPMDMXとPMDRCの連携でも要注意項目だ。
どうやっても今直すヒマなんてない。なんせ飯を食って20時過ぎには帰宅してきているのに、風呂入って洗濯しながらちょっと打ち込み作業して気が付いたらもうこんな夜更けだもの。しかもS5000のロータリーエンコーダが壊れたし、中古だからしょうがないけど。っていうか、ロータリーエンコーダなんて起動直後しか使わないけどなww
・・・・今更先週末の話だw
で、最近PMDMXを使ってFM24音など使ってみたものの、久しぶりな上に2本のMMLを同期しなきゃならんので、いろいろと普段使わないMML命令を使うことになる。が、PMDMML.MANが8カラムtabテキストなのでちょっと困った。うーん。
ということで、秀丸マクロでPMDMML.MANをHTML化などしてみたわけだ。例によって、作業時間は仕事場での昼休みを割り当てて、コミケ作業に影響が出ないようにはしている(が、コミケ作業は遅れている。もはや遅れるのが予定調和というのも情けない話だが)。
久しぶりに秀丸マクロを組んだが、これはMMLにも当然応用できるわけだが、今までほとんどやったことがないなあ。なんでだろう、便利なのは判るんだが、カタルシスに欠けるというか、直感をロジックに置き換えるの頭がないのか、そんな感じか。
で、そのまま仕事場での昼休みは終わり、本業用のツールを作っている最中に「あれ? このロジックは昔組んだことがある」とPMDRC.dllのソースを引っ張り出したら、なんと4年越しのバグを発見ww
今直すヒマなんてないがメモっておく。
・局所ループ内の最後で転調すると、ループ終了記号と前後逆になる
・相対転調と絶対転調の内部処理が交錯していて正しい値が出ない
この辺はPMDMXとPMDRCの連携でも要注意項目だ。
どうやっても今直すヒマなんてない。なんせ飯を食って20時過ぎには帰宅してきているのに、風呂入って洗濯しながらちょっと打ち込み作業して気が付いたらもうこんな夜更けだもの。しかもS5000のロータリーエンコーダが壊れたし、中古だからしょうがないけど。っていうか、ロータリーエンコーダなんて起動直後しか使わないけどなww
2008年07月06日
PMDMX(6)
PMDMX0.exe0.96aとMCMX1.exe1.31にて、前回の宿題の(1),(3),(4)をクリア。
贅沢な実行ログを見る
FM24音/SSG12音/8bitPCM36音/16bitPCM24音、なんて無意味に贅沢な仕様なんだろうか。ログの通りPZIやPVIをしこたま読み込んでみたものの、もちろん全てを使いこなせることなどありえないww
ついでに、ミキサーのオーバーフロー警告を実装。2モジュールでいくつか打ち込んでみたが、いつも通りの音量設定だと、頻度としては毎分数十サンプルのオーバーフローが出る。ミキサーは32bit整数演算なので、リアルタイム演奏は16bitのまま、WAVファイル出力は24bit出力する機能を付与すれば解決する問題なのかもしれないな。
贅沢な実行ログを見る
FM24音/SSG12音/8bitPCM36音/16bitPCM24音、なんて無意味に贅沢な仕様なんだろうか。ログの通りPZIやPVIをしこたま読み込んでみたものの、もちろん全てを使いこなせることなどありえないww
ついでに、ミキサーのオーバーフロー警告を実装。2モジュールでいくつか打ち込んでみたが、いつも通りの音量設定だと、頻度としては毎分数十サンプルのオーバーフローが出る。ミキサーは32bit整数演算なので、リアルタイム演奏は16bitのまま、WAVファイル出力は24bit出力する機能を付与すれば解決する問題なのかもしれないな。
2008年07月02日
PMDMX(5)
PMDMXを使って1曲打ち込んでみた。が、FM12音という構成をまだ使いこなせていないのでサンプルには出来ないなあ。サンプルに出来そうな曲は別に作ろう。とりあえず、使ってみてからちょっと思いついた、実装すべき機能のメモ。
(1)MCMX1.exeに対話プロンプトを実装
コマンドラインアプリだからエクスプローラから直接起動できないので面倒だった。コマンドライン引数がない場合はMMLファイル名を入力させるようにすることで、GUI一発起動から操作できるようになる。作り込みにも時間は掛からないし、重要度も高い。
(2)MCMX1.exeからPMDRC.dllを呼んで長さをチェック
ViewKEYで便利だった「パートごとの長さを表示する機能」はPMDWinで打ち込みしている限り使えない(FMPMDにも実装されていない)ので、これを追加する。演奏ファイルを読み込むロジック自体を組み込むのは製造に時間が掛かってアプリも重くなるので、PMDRC.dllを使う。手間が掛かるので、すぐに実装というわけには行かないが、いつかは欲しい機能だ。
(3)MCMX1.exeから3Mと4Mを指定
1個のMMLでPMDWin4モジュールを制御するMMLを書くことは出来ないが、3/4番目のモジュールに読ませるべきデータを別途指定できるようにする。3M/4Mを構成するMML名をMCMX1.exeに与えて、子プロセスからコンパイルさせてMX0ファイルを一括作成すればOKか?
MCMX1はPMDMX0と違って簡単にモジュール数を増やせる構造でない(MC.exeも影響している)ので、そこらへんの解決には手間が掛かりそうだ。
(4)PMDMX0.exeの規定設定default.mx0の別名を設定
環境変数pathに登録されたディレクトリに適当に放り込んだとき、PMDMX0.exeとdefault.mx0が離れたところに存在するのは不便だ。多分PMDMX0.mx0というファイル名になるだろうが、作ってみてからの話だ。チョロいので、すぐに対応しよう。
(5)PMDMX0.exeのミキシングボリューム調整
PMDWin.dllを4モジュールまで読み込むとなるとクリッピングが多発するのは火を見るよりも明らかなので、何らかの回避方法を模索する。多分単純に除算することになるだろうが、自動処理ならユーザにレポートを上げることも必要。
--------
やっぱり、使い込んでみると不満点は出るなあ。
(1)MCMX1.exeに対話プロンプトを実装
コマンドラインアプリだからエクスプローラから直接起動できないので面倒だった。コマンドライン引数がない場合はMMLファイル名を入力させるようにすることで、GUI一発起動から操作できるようになる。作り込みにも時間は掛からないし、重要度も高い。
(2)MCMX1.exeからPMDRC.dllを呼んで長さをチェック
ViewKEYで便利だった「パートごとの長さを表示する機能」はPMDWinで打ち込みしている限り使えない(FMPMDにも実装されていない)ので、これを追加する。演奏ファイルを読み込むロジック自体を組み込むのは製造に時間が掛かってアプリも重くなるので、PMDRC.dllを使う。手間が掛かるので、すぐに実装というわけには行かないが、いつかは欲しい機能だ。
(3)MCMX1.exeから3Mと4Mを指定
1個のMMLでPMDWin4モジュールを制御するMMLを書くことは出来ないが、3/4番目のモジュールに読ませるべきデータを別途指定できるようにする。3M/4Mを構成するMML名をMCMX1.exeに与えて、子プロセスからコンパイルさせてMX0ファイルを一括作成すればOKか?
MCMX1はPMDMX0と違って簡単にモジュール数を増やせる構造でない(MC.exeも影響している)ので、そこらへんの解決には手間が掛かりそうだ。
(4)PMDMX0.exeの規定設定default.mx0の別名を設定
環境変数pathに登録されたディレクトリに適当に放り込んだとき、PMDMX0.exeとdefault.mx0が離れたところに存在するのは不便だ。多分PMDMX0.mx0というファイル名になるだろうが、作ってみてからの話だ。チョロいので、すぐに対応しよう。
(5)PMDMX0.exeのミキシングボリューム調整
PMDWin.dllを4モジュールまで読み込むとなるとクリッピングが多発するのは火を見るよりも明らかなので、何らかの回避方法を模索する。多分単純に除算することになるだろうが、自動処理ならユーザにレポートを上げることも必要。
--------
やっぱり、使い込んでみると不満点は出るなあ。
2008年06月30日
PMDMX(4)
依然として、仕事場(本業)での昼休みはPMDMXの時間。
MCMX1.exeとPMDMX0.exeはそれぞれ1.26と0.95fにVersionUP。今回の目玉は「モジュール数倍増(2→4)」「MML監視自動連続コンパイル」「再生制御」「音質向上」あたりか。これで、MCMX1.exeを立ち上げておけばMMLを書いて上書き保存するだけでコンパイル→演奏までリアルタイムで出来るようになった。
まあモジュール数が4に増えたとしても、買いに行く服がない制御できるコンパイラがないんだけどね。だれか作ってくれないかなw
一応制御ロジックは99個までPMDWin.dllをロードできるけど無意味だから4個まででロックしている。5個以上ロードしたい人は申し出てくださいw
もうコマンドライン版では、実装されてない当面必要な機能は残ってないなあ。VolumeDownはMMLから制御できるし、常駐機能も付いたし、必要な情報は全部表示してるし。ここまでテキスト版で機能を実装しちゃうとGUI版開発の必要性を感じなくなってきた、もしかして裏目に出た?
打ち込み作業をする身分としては演奏モニタも要らないし、データの配布も昔のように行われるわけではないので聴いてもらうにもやっぱり演奏モニタは要らないし、GUIでないと出来ない機能ってなんかあるだろうか? ない? MMLとPCMを連携する環境くらいか?
っつったってなあ、テキストエディタは秀丸が一番使いやすいし、PCMエディタをGUIで新たに開発する手間は償還できないだろうしなあ。どーするかね。
とりあえず、誰かが使うとはちょっと考えられないが、自分の脳味噌を整理するためにサンプルMMLを書くか・・・・。
MCMX1.exeとPMDMX0.exeはそれぞれ1.26と0.95fにVersionUP。今回の目玉は「モジュール数倍増(2→4)」「MML監視自動連続コンパイル」「再生制御」「音質向上」あたりか。これで、MCMX1.exeを立ち上げておけばMMLを書いて上書き保存するだけでコンパイル→演奏までリアルタイムで出来るようになった。
まあモジュール数が4に増えたとしても、
一応制御ロジックは99個までPMDWin.dllをロードできるけど無意味だから4個まででロックしている。5個以上ロードしたい人は申し出てくださいw
もうコマンドライン版では、実装されてない当面必要な機能は残ってないなあ。VolumeDownはMMLから制御できるし、常駐機能も付いたし、必要な情報は全部表示してるし。ここまでテキスト版で機能を実装しちゃうとGUI版開発の必要性を感じなくなってきた、もしかして裏目に出た?
打ち込み作業をする身分としては演奏モニタも要らないし、データの配布も昔のように行われるわけではないので聴いてもらうにもやっぱり演奏モニタは要らないし、GUIでないと出来ない機能ってなんかあるだろうか? ない? MMLとPCMを連携する環境くらいか?
っつったってなあ、テキストエディタは秀丸が一番使いやすいし、PCMエディタをGUIで新たに開発する手間は償還できないだろうしなあ。どーするかね。
とりあえず、誰かが使うとはちょっと考えられないが、自分の脳味噌を整理するためにサンプルMMLを書くか・・・・。
2008年06月26日
PMDMX(3)
というわけで、ようやく実用的になってきた感のあるPMDMX0.exe。前回の課題をどれだけクリアできたかな・・・・と。
(A)MC.exeは長いファイル名が扱えないのでGetShortPathName(SDK)必須
(B)PMDWin.dllによる演奏が重い。21演奏秒/演算秒程度の性能しか出ない
(C)いちいちメディアプレーヤーが立ち上がるのはウザい
(A)については、短い名前のテンポラリを作って受け渡しすることで解決した。MC.exe自体がもう15年以上も前の設計だもんなあ。
(B)と(C)については、PMDMX0.exe自体がリアルタイム再生機能を実装することで解決。一応WAVPLAY.exeという軽量WAV再生アプリも作ってはみたが、根本的に解決したので要らないかなあ? まあこれはこれで有用なので、一応残しておこう。
あとはボリューム調整機能と各種テストくらいか。8月にはデータ作成に戻れそうだ。
(A)MC.exeは長いファイル名が扱えないのでGetShortPathName(SDK)必須
(B)PMDWin.dllによる演奏が重い。21演奏秒/演算秒程度の性能しか出ない
(C)いちいちメディアプレーヤーが立ち上がるのはウザい
(A)については、短い名前のテンポラリを作って受け渡しすることで解決した。MC.exe自体がもう15年以上も前の設計だもんなあ。
(B)と(C)については、PMDMX0.exe自体がリアルタイム再生機能を実装することで解決。一応WAVPLAY.exeという軽量WAV再生アプリも作ってはみたが、根本的に解決したので要らないかなあ? まあこれはこれで有用なので、一応残しておこう。
あとはボリューム調整機能と各種テストくらいか。8月にはデータ作成に戻れそうだ。
2008年06月20日
PMDMX(2)
仕事場で昼休みにコソコソと開発してるのでなかなか捗らないが、ようやくMMLから1passで再生まで出来るようになった。
(1)コンパイラMCMX1.exeが独自形式.MMLを読み取る
(2)PMDPPZ用MML2個に分割する
(3)MC.exeを起動してPMDPPZ用.MMLをコンパイルする×2
(4)MCMX1.exeからPMDMX0.exeへの演奏指示データ.MX0を作成する
(5)MCMX1.exeからPMDMX0.exeを起動し.MX0を渡す
(6)PMDMX0.exeがPMDWin.dllの複製を作成しロードする×2
(7).MZを読んで演奏結果PCMデータを作成し、ミキシングする
(8)演奏結果PCMデータ.wavを作成し、MediaPlayerを起動し渡す
(9)無事にFM12音が響き渡る
なんという積み上げ構造ww
まあ、コマンドラインでやろうとすると、これくらいは1passで出来ないとちょっと面倒なので仕方がない。なんかGUIを作る際には全然関係ないロジックなので回り道以外の何者でもないが、やれることはやれるうちにやっておきたいというのが本音。どうせ、出先で打ち込むときはVAIOのC1なので、少しでも軽いものを作っておきたい。
メモっておくべき事柄一覧。
(A)MC.exeは長いファイル名が扱えないのでGetShortPathName(SDK)必須
(B)PMDWin.dllによる演奏が重い。21演奏秒/演算秒程度の性能しか出ない
(C)いちいちメディアプレーヤーが立ち上がるのはウザい
MCMX1.exeもPMDMX0.exeも重要な機能の実装は終わったので、明日からはドキュメント整備と一部のリファクタリング、それに(C)と(B)の解決作業に移行しよう。コマンドラインのWAV再生アプリを作るか、PMDMX0.exeに組み込むか・・・。
性能についてはちょっとPMDWin.dllに手を入れるわけには行かないので、なんか回避方法を考えないといけない。といっても多分限界はあるので、リアルタイム再生で凌ぐしかないなあ。
長ったらしい実行ログを見る奇特な人はクリック
(1)コンパイラMCMX1.exeが独自形式.MMLを読み取る
(2)PMDPPZ用MML2個に分割する
(3)MC.exeを起動してPMDPPZ用.MMLをコンパイルする×2
(4)MCMX1.exeからPMDMX0.exeへの演奏指示データ.MX0を作成する
(5)MCMX1.exeからPMDMX0.exeを起動し.MX0を渡す
(6)PMDMX0.exeがPMDWin.dllの複製を作成しロードする×2
(7).MZを読んで演奏結果PCMデータを作成し、ミキシングする
(8)演奏結果PCMデータ.wavを作成し、MediaPlayerを起動し渡す
(9)無事にFM12音が響き渡る
なんという積み上げ構造ww
まあ、コマンドラインでやろうとすると、これくらいは1passで出来ないとちょっと面倒なので仕方がない。なんかGUIを作る際には全然関係ないロジックなので回り道以外の何者でもないが、やれることはやれるうちにやっておきたいというのが本音。どうせ、出先で打ち込むときはVAIOのC1なので、少しでも軽いものを作っておきたい。
メモっておくべき事柄一覧。
(A)MC.exeは長いファイル名が扱えないのでGetShortPathName(SDK)必須
(B)PMDWin.dllによる演奏が重い。21演奏秒/演算秒程度の性能しか出ない
(C)いちいちメディアプレーヤーが立ち上がるのはウザい
MCMX1.exeもPMDMX0.exeも重要な機能の実装は終わったので、明日からはドキュメント整備と一部のリファクタリング、それに(C)と(B)の解決作業に移行しよう。コマンドラインのWAV再生アプリを作るか、PMDMX0.exeに組み込むか・・・。
性能についてはちょっとPMDWin.dllに手を入れるわけには行かないので、なんか回避方法を考えないといけない。といっても多分限界はあるので、リアルタイム再生で凌ぐしかないなあ。
長ったらしい実行ログを見る奇特な人はクリック
2008年06月13日
PMDMX(1)
前にも書いた通り、夏コミは落選したのでとりあえずPMDMXはWebサイトでまったり進行させていくことに。まずは現時点で(致命的なバグなしに)動くものを整理した。
http://judstyle.jp/wiki/Category:PMDMX
といっても、肝心のPMDMX1.exeはまだ致命的ないくつかのバグが取れていないので、先行演奏データ作成用プロトタイプのPMDMX0.exeしか置いていない。まだあんまり面白いところではない。コンパイラMCMX1.exeとPZIユーティリティPZIUTYMX.exeはほぼ要求仕様を満たした状態でリリース完了。PMDMX0.exeは致命的なバグの対策と最低限のエラーチェックなどを組み込んでとりあえずリリースしてる状態。
まー、先行演奏データ作成っつっても、リアルタイム再生も演奏モニタもないので、多分PMDを相当使い込んでいる人でないとどうにもならないんだろうなあ。しかも動かすためにはPMDWin.dllのコピーを作らなきゃならないんだ、これだけでも自動化しておこうかね。
俺自身は、PMDWin.dll+FMPMDで作るよりも作りやすいけどね。PMDWin.dllで打ち込みする際に、PMD98と比較してもっとも苦労するところは#JUMPが使えないことだから。慣れてしまうと、演奏モニタはいらないし。マルチモジュールじゃないFM紅魔郷も、#JUMPの都合でこっちを使って打ち込んだりしてたなあ。
ところで、今更PMDでナニかやろうって人はいるのかな? 多分誰も利用者はいないと思うんだけど、作ること自体も楽しいし、打ち込みのツールとして自分が使うのでモチベーションには困らないなあ。いわゆる俺様ツール。せっかく作るので誰かに使ってみて欲しいとは思うんだけど、こればっかりは望んで得られるものじゃないし、PMD自体が前世紀のものだし。
でも作ったデータを丸々Webサイトで公開するのは躊躇われるなあ。勿体無い根性が出てくるし、何より1個のファイルで動作するものじゃないからねえ。
http://judstyle.jp/wiki/Category:PMDMX
といっても、肝心のPMDMX1.exeはまだ致命的ないくつかのバグが取れていないので、先行演奏データ作成用プロトタイプのPMDMX0.exeしか置いていない。まだあんまり面白いところではない。コンパイラMCMX1.exeとPZIユーティリティPZIUTYMX.exeはほぼ要求仕様を満たした状態でリリース完了。PMDMX0.exeは致命的なバグの対策と最低限のエラーチェックなどを組み込んでとりあえずリリースしてる状態。
まー、先行演奏データ作成っつっても、リアルタイム再生も演奏モニタもないので、多分PMDを相当使い込んでいる人でないとどうにもならないんだろうなあ。しかも動かすためにはPMDWin.dllのコピーを作らなきゃならないんだ、これだけでも自動化しておこうかね。
俺自身は、PMDWin.dll+FMPMDで作るよりも作りやすいけどね。PMDWin.dllで打ち込みする際に、PMD98と比較してもっとも苦労するところは#JUMPが使えないことだから。慣れてしまうと、演奏モニタはいらないし。マルチモジュールじゃないFM紅魔郷も、#JUMPの都合でこっちを使って打ち込んだりしてたなあ。
ところで、今更PMDでナニかやろうって人はいるのかな? 多分誰も利用者はいないと思うんだけど、作ること自体も楽しいし、打ち込みのツールとして自分が使うのでモチベーションには困らないなあ。いわゆる俺様ツール。せっかく作るので誰かに使ってみて欲しいとは思うんだけど、こればっかりは望んで得られるものじゃないし、PMD自体が前世紀のものだし。
でも作ったデータを丸々Webサイトで公開するのは躊躇われるなあ。勿体無い根性が出てくるし、何より1個のファイルで動作するものじゃないからねえ。