MIDI/CV ウィンドコントローラ用です。Analog2.0 規格です。
Gate + CV に加え、エクスプレッション情報を出力できます。
昨年のシンセサミットに合わせて作ったのですが、音量の変化がなにか不自然で、また音量変化の境目でいやなノイズが入るため、「要改善」のまま放置してありました。
ウィンドを試すならまず WX5 + MIDI が立ち上がり早いです。ということで、この MIDI/CV モジュールに改善かけました。
改善は、ハード・ソフト両方にかかりました。
回路図はこちら
Gate/CV はライフラインに戻しています。エクスプレッションは J2, J3 から出力。ベンドは別系統に分けて IC3A から CV に加えていますが、回路が間違っています。要修正。
回路の改善点は、J3 出力をアンチログにしたのが一番大きいところ。SX-150 に続き性懲りも無く温度補償入れてません。でも結構大丈夫なようです。
あとは、LPF のカットオフ周波数を全体下げました。
ソフトの改善点として、エクスプレッションの遷移を滑らかにしました。これで、エクスプレッションが変化するたびにがりがり雑音が出ていたのがおさまりました。
これを使って Analog2.0 から音だししてみたのですが、それについては、後日別記事でリポートします。
エクプレッションの遷移は移動平均をとるような処理でしょうか？
PWM の分解能を上げて（オーバーサンプリングのイメージ）、エクスプレッションの値が変わったら、PWM のデューティーサイクルをゆっくり動かす、というような処理を入れています。
関連のコードを断片ですがのせてみます。
プロセッサは ATTiny2313
Timer1 は 10bit の fast PWM に設定されています。
MIDI の Expression メッセージを受信すると、SetExpression() が呼ばれます。
PWM のスレッショールドの更新は、PWM 1サイクルごとにじわっとやるようになっています。
これでもまだ速すぎで、ノイズはなくなりましたが、まだかくかくしています。もう少し気合を入れてアルゴリズムを組んだほうが良いかもしれません。
volatile uint16_t volume; void SetExpression(void) { volume = 1023 - channel_Expression * 8; } ISR(TIMER1_OVF_vect) { if (OCR1B == volume) { return; } if (OCR1B > volume) { --OCR1B; } else { ++OCR1B; } }なるほど、サンプリング周波数 19.5kHz で直線補間で追っかけさせているわけですか。これでも速いとなると移動平均フィルタではタップ数が大きくなってしまうかもしれませんね。
アルゴリズムは、どうしようもならない限り現行のアホアホ方式で行くとして、
1. PWM の毎サイクルでの更新を間引く (が、時間方向にカクカクしやすい)
2. PWM のビット数をさらに増やす (が、周期が遅くなって LPF 要修正になりかねない)
3. LPF のカットオフ周波数をさらに落とす
の三つの方法をバランスとりながら進めるのが良いかなと思っています。
ここから先はヒューリスティックなチューニングの世界になりそうです。
あと、ピッチベンドもカクカクで困っているので、ピッチベンドにもこれに似た仕組みが必要かもしれません。回路の修正と合わせて要改善です。
あ、だけど、現行の方式だと、急激な expression の変化に対する追従が鈍いかもしれないから、移動平均も一度試したほうが良いかもです。
あるいは、タップ数をけちるために自己回帰でやってみるとか？
++, — の場合は傾きが1固定ということですね。追従性には限界がありますが、しかし一方でARモデルにすると今度はオーバー/アンダーシュートがっ！
ああっなるほどっ！
やっぱり色々と試行錯誤が必要そうですね。
チェック済かとはおもうけど、ラニングステータスこぼしてるって事ない？
僕は、ベンドホイルとモジュレーションホイルの処理でミスってて、ベンドホイルを回すとボリボリ音が出るなんてな事がありました。
このアルゴリズムだと、コントローラからのボリュームデータが、出力に直結してない状態ですよね。
シーケンサ経由で、エクスプレッション出すと、そっちが最適化してて、（てか、データ量増やしてて）平気とか無いかしら？！
アンチログ変換はほしいかもしれませんね、確かに。
ソフトの高速化のために、なんか、色々検討するんだったら、++方向は高速さが要求されることが多いけど、–方向はのんびりでもいいことが多いかもしれないとか、差をつける手はあるかもしれません。
> チェック済かとはおもうけど、ラニングステータスこぼしてるって事ない？
ここの解説、もっと詳しくよろしくお願いでっす。
PWM の出力をオシロで観測する限り、生 PWM では変なデータは出ていないのではありますが念のため確認したいです。と、いってもランニングステータスってなんのことやらわかりません。
こういった CV 丸めの処理は Doepfer A-100 シリーズの MIDI/CV にも入っています。良くできていて、設定で ON/OFF できます。多分ディジタルフィルタ使っています。
ランニングステータス：
MIDIでは通信路のデータ量を削減するためにある条件のもとでステータスバイトを省略して送ることが出来るようになっています。
http://www.tim.hi-ho.ne.jp/t-inukai/midi01.html
http://www.pluto.dti.ne.jp/~daiki/Midi/AboutMidi_Note.html
検索するとNote On/Offメッセージをサンプルにした例に行き当たるかもしれませんが、MIDIチャンネルメッセージではランニングステータスになり得るのでMIDIパーサで対処しておく必要があります（少なくともボイスメッセージは。モードメッセージではあんまりないかも。とはいえモードはコントロールチェンジと同じステータスアサイン）。
私は以前対応を忘れていたところがあって、MIDIパーサのステートマシンが一瞬トチ狂って（マイナループは収束するようになっているのでステートマシンがスタックすることはない）周辺のレジスタをいじってしまってMIDI-CVが変なモードに入り込んでしまったことがあります。
PWMの部分で観測してもわからないんじゃないかなと思います。
ランニングステータス情報ありがとうございます。
後ほどゆっくりコード確認してみますです。
生PWM を確認するときには、タイマーのプリスケールを最大にしてスピードを落として観測します。確かにとってもわかりにくいですが、波形の乱れは見られないのですよね～。まあその、乱してみたらどうなるか、というのは試してないのですが。
MIDIチャンネルメッセージの代表格は、ノートオン/オフ。このほか、モジュレーションホイル、ピッチベンド、コントロールチェンジ（エクスプレッションもコレね）とかもあります。で、こいつらは続けてたくさん来る可能性がありますね。
で、さっき送ったメッセージと同じで、パラメーターが違うだけの時、メッセージの種類は送らず変更になったパラメーターだけ送ってよこします。いつもなら3バイトで完結のメッセージが2バイトしか来ないんです。
僕が掘ったバグは、ノートオン/オフはこの対策してあったんだけど、ホイルと、コントロールチェンジ（モジュレーションホイル）はこの対策がこぼれてて、のんびりホイルを回すと、ちゃんと、最適化されて3バイト送られてくるんだけどギュっと回すと2バイトに省略して送ってくる(そんなソフト良く書いたなあ！！）のでバグ付きのメッセージパーサーがこけて、1メッセージおきに、しかモジュレーションデータが送られない状態になってました。
MIDIを送る側の仕様なので、いつでもそうなるとかどの機材でもそうなるとかでもないんです。送信のメカを変えると出たり出なかったりする問題です。シーケンサ経由で鳴らすと、シーケンサが欠けたメッセージを補完したりするのか、無事に動いちゃったり、そのぎゃくになったりという見つけにくいバグなんです。
ちゃっくさんとかぶったー
ランニングステータス、チェックしたら、見事に未処理でした。
直してみました。が、あんまりかわらないかも？
と、思いましたが、以前より滑らかさは増したような気がします。
ご指摘ありがとうございました。
一度、もっとでかいプロセッサ使って MIDI の全メッセージに対応したデコーダのプログラムを組んでみたい気もします。