MML作成支援ツール 音楽つくろうぜ！ Ver 0.19 【D4DB4KD】 ページ送り時の画面のチラツキを低減。 GB風カラーテーマ追加。

項目の選択って奥が深いですね。ユーザーにとって使い易いものとなると大変です。

MML作成支援ツール 音楽つくろうぜ！ Ver 0.18 【53N3S3JJ】 (ソフトウェア)鍵盤を配置しました。 とりあえず、現在の音色を使って鳴らすだけの機能です。

ヘ音記号(ト音記号)の切り替えはMENUからのCLEFコマンドで可能です。すでに配置済みの音符を動かさないという条件なら、CLEFコマンド選択後の警告の3択で「X」ボタンを押す事で実現できると思います。思ったのと違うかもしれないかもしれないので実行前にセーブしておく事をオススメします。

和音について チャンネルを複数使えば可能です。□で囲まれた数字0〜15をタッチする事でチャンネルを切り替える事ができます。 チャンネル0にド。チャンネル1にミ。チャンネル2にソ。 これでドミソの和音が完成です。

チャレンジャー好きだったなぁ…

MML作成支援ツール 音楽つくろうぜ！ Ver 0.17 【NKSEPXQD】 演奏開始をチャンネル毎に遅らせる機能(DELAYコマンド) (これを上手く使えばアルペジオが表現できるかも)

Windows 3.x の事を れい さんに先に書かれてしまった。 タイムラグが憎い。

Windows 3.x はDOS から起動してたけどOS って言ってましたね

私もこれやりましたが、笑われてしまいました。

。o O(他の要因の様な気もするが…)

ビッグバン!?

> りゅうまご さんへ テストプログラムがややこしくなるというのは良くありますね。それだけその関数は複雑って事かもしれません。 > れい さんへ うーん、ワイルド。 問題がある場合に場所を特定するのが難しそうですが… > Godot さんへ ナイスな指摘です。 確かにあの例ではテストパターンが圧倒的に足りないです。いきなり3の場合に上手く動作しない事もあるし、負の値の場合にエラーで停止する可能性だってあります。 よって、実際にはもう少しパターンを増やす必要がありそうです。

単体テストはJavaのJUnitなんか有名ですよね。 単体テストは万能ではないので、操作が必要なテストとか見た目とかゲームの面白さとか、テストできないです。 操作を記録して再現するというのは良いアイデアだと思います。

私が作成している「音楽をつくろうぜ！」では700近いパターンのテストを行っており、掛かる時間も1〜2秒とかそんなです。手動のテストではとても実現できません。 でも単体テストを取り入れようとすると、サブルーチンを関数(DEF)で用意し、独立性を高くしないといけないので、途中から採用するというのは難しいです。 単体テストは奥が深く、ここではとても書ききれないので興味がある方は自分で調べてみても良いと思います。 長文失礼しました。

単体テストとは何ぞや？という人も居ると思うので簡単に説明すると、ある関数が期待通りの通りの動作をしているか？というのをテストする手法です。 例えば、引数に整数を指定すると偶数かどうかを判定する自作関数(IS_EVEN)があるとします。 その場合のテストはこんな感じです。 IS_EVEN(1)が偽(FALSE)を返す IS_EVEN(2)が真(TRUE)を返す これが成り立たない場合はエラーとしてユーザーに通知する様な仕組みを別途用意しテストします。 プチコン3号には複数のスロットがあるので、メインのプログラムはスロット0。単体テストはスロット1という構成にすると構成的に分離できて良いと思います。 単体テストの最大の魅力は、テストのパターンを一度作ってしまうと、同じテストを何度も高速に行えるという点です。

皆さんプログラムのテストはどの様にされてますか？ 私の場合、単体テスト(UnitTest)という手法を使ってテスト(デバッグ)しています。

MML作成支援ツール 音楽つくろうぜ！ Ver 0.16 【QDK5J443】 仮確定時にR押しながら十字キーの上下でオクターブ単位での移動。 セーブ時に音符がずれるケースがあるので対応。

ああ! てっくさんと同じ様な事を書いてしまった。失礼しました。

某ギャンブル漫画みたいに、グー・チョキ・パーをそれぞれに出せる回数に制限を設けたり、何かしら制約をつけると楽しくなるかもしれません