返事を書く|リスト

8697	Root	▼[8700] ▼[8760]
設計と製作 pARM ver2.0 開発始動（か？） #8697 takeda　(2007年12月04日19時20分) アイディアをまとめるべくパネルデザイン、pARMを踏襲しつつ、Ver2.0っての考えてみた。 http://www.aleph.co.jp/~takeda/radio/parm/V2panel.pdf 積極的に、マイコン導入しよーっと。そのかわり（というか、どうせ数は多くないだろうから）僕も、マイコンの書き込みサービスみたいなことやろうかと思い始めてます。書き込み環境とかの紹介とかも積極的にやらなきゃカナとか。 LFOは、サイン波のみ。EGは、ARじゃなくて、ADSに変更。他の楽器との組み合わせで使う前提で、外部には手元に、ミキサーがあるはずとボリュームは省略。（カツミさんや、analogさんには常々、ボリュームは省略するなと言われてるんだよなあ..）オシロマーク無しにしてでも、ボリュームはつけるべきかなあ...。 その代わり、鍵盤のモジュレーションホイールのソースに、LFOと、EGが選べるようにしようかなかなと。シンクできるのに、モジュレーションできないのはやっぱ、ちと...。 マイコンのAD入力には、 1.EGのA、D、S、 2.LFOのスピード、 3.モジュレーションソースの選択/マックスレベル設定。 4.マスターピッチの6ch。 モジュレーションソースの動作は、センターでモジュレーション無し。左に回すと、ビブラート、左に回すと、EGでシャクリが設定できてそれぞれ最大の深さを設定する。演奏時には、ホイールを回して、微妙に調整できる。 EGのときは、オシレーター片側だけに掛って、シンクかけたときのネイロの変化を演出。LFOの時は両方のオシレーターに掛るようにしてビブラートの表現。 ここ、なんか、変な気もするけど、pARMのキャラを演出するポイントかなと。 マイコンの出力は、 1.ピッチCV（ベンド、モジュレーションホイルで決めるLFOと、マスターのピッチ混み）、 2.ホイルでレベルが代わるEG（AD入力のほうの設定で、出ない時もあるけど）シンクのVCO用 3.生のEG出力（VCA、VCF用） 3系統のDA。 4.Analog2.0との連携で、ゲートを1発。 ディケイは、MIDI入力のダンパーで、オンオフ。 余裕があれば、改造用に、LFOの波形に正弦波と、矩形波を選ぶスイッチと、ディケイのオンのスイッチをビットで外にだすツモリ ソフトウエアは、RJBさんのワンチップEGをAVRに移植。さらにChuckさんのLFOと、僕のMIDIパーサーも乗せる。(乗り切るかしら、かなり心配！）いまのところ、ATMEGA48を想定。 言語はC。はみ出したら、部分だけでも、ASM化。コノ部分だけで、名刺サイズに収められれば、現行のケースには入りそう。 どちらにせよ、RJBさんのワンチップEGのAVRへの移植はやりたい...。

返事を書く|リスト

8700	▲[8697]	▼[8705] ▼[8708]
設計と製作 Re:pARM ver2.0 開発始動（か？） #8700 gan　(2007年12月04日23時07分) Analog2.0 との連携、うれしいです。ありがとうございます。 Analog2.0 と規格をあわせる、というのは、CV と Gate の電圧をあわせる、という点で考えればよいでしょうか。実は信号レベルも決まっていますが、パッチでなく音源レベルであわせるならあまり重要ではないですね。 Analog2.0 内部の話では、設計上の特徴は、 1. ライフラインとよばれる共通バスで電源とコントロールを供給する。 2. 基板のサイズ、穴位置、ボリューム位置が決まっている。穴位置はいわゆる秋月基板互換。 3. 信号・モジュレーションの電圧レベルが規格化されている。 というところで、pARM と絡んでくるのは、実は3の部分だけ？かな？ ですが、供給コントロールは、現在は CV と Gate のみですが、これに加えてベロシティーやアフタータッチなどの演奏情報も是非加えたい！と思ってます。そうするとまた面白い展開があるんじゃないでしょうか。 （以下余談） でもそれをするには、供給コネクタは今の、10ピンを2本ずつまとめるやり方では足りず、 1. 電源は従来どおり2本ずつまとめる。残り4本は一本ずつ独立したコントロールにして10ピンのまま か、 2. 全ての電源・信号を2本ずつまとめる。コネクタのピン数は増やす のどちらにするか迷ってます。 「なんのことかわからん」というかたは、こちらの http://www29.atwiki.jp/synth-kit/ 「ライフライン」の設計を見ていただけるとうれしいです。よけいわかんなくなる？ （と言う議論を Mixi 内じゃなくここでやっちゃっていいんだろうか？）

返事を書く|リスト

8705	▲[8700]	なし
設計と製作 Re[2]:pARM ver2.0 開発始動（か？） #8705 genie　(2007年12月05日06時38分) > どちらにするか迷ってます。 3. ・・・なんてのもあったりすると思うので、ここでライフラインの変更はしない方が良いと思いますよ。変更は私の専門分野です。(こらこら

返事を書く|リスト

8708	▲[8700]	▼[8710]
設計と製作 Re[2]:pARM ver2.0 開発始動（か？） #8708 takeda　(2007年12月05日21時38分) Analog2.0との連携ってのは、ちょっと乱暴な発言でしたね、申しわけない。実際に電気的な連携の部分は、1V/1OctのCVとGATE、出力のオーディオがAnalog2.0に接続できるだけですね。Analog2.0との連携と呼ぶには希薄すぎる関係かも。 むしろ、初心者のためのアナログシンセという部分でのコンセプト的な連携の意味合いのほうが強いですね。 とはいえ、たとえば、pARMは電源が無いんです。別にもう1箱、pARMよりでかい箱が必要になります。 各自で用意するって事なんだけど、たとえば、これが、Analog2.0の電源バスに接続できるアダプタを作るとか、あるかもしれませんね。Analog2.0のライフラインとのアダプタを作って、Analog2.0から電源をもらって、お返しに、MIDIからコンバートした、CV/GATEを返すとかできそうです。さらに、たまたま、pARMも音出ますからミキサーに戻すとか。 サミットのとき、shinさんの巨大なラックの裏も拝見したんですが、全てのモジュールは、DINの5pinのコネクタでバスになってます。まだ、仕様は公開されてないんですが、もしこれが公開されれば、変換コネクタ作れば、shinさんのラック、100M、pARM、Farm、analog2.0のハーモニーも夢じゃないですね。多分、変換すれば、ドーファーとかのモジュールも混在できます。 ライフラインの拡張構想は理解できますが、むずかしそーです。 おっしょさんなんか、MIDI-CVの出力は、AD出力は8本が最低ライン。16本ないと満足できない、と仰ってました。(面倒臭くせえやつだなあー！2つでじゅーぶんですよ、判ってくださいよーって、もちろん笑うところだけど） というわけで、追加のCVの規格化始めると、切り無いです。ChuckさんのBlogで、MIDI-CV作ろうとして、なんのCVをだすかってんで、もーケンケンガクガクピョンピョンやったのが、ツイこないだな気がします。 基本のライフラインは既に規格化された、+ / - / GND (電源) CV /GATE の5本、それぞれ2本でセット合計10ラインとして、あとは全て追加オプションの扱いで表でパッチングが前提とするほうが、拡張性一番高いと思います。 パネルに追加の穴があけられるかどうか心配だけど、プリパッチ用のジャックを追加、さらに、Chuckさんと連携して、4CV+4gate+Grandを1コネクタでパネルに接続できる別規格を検討するほうがいい気がします。 まあ、パネルの裏にこっそり伸びるケーブルが1本あるってのも有りだと思いますけど。 そうそう、サミットのモチベーションアップ効果がそこら中で起こってて、モジュラー作るぞ、という声がちらほら聞こえてきたりしてます。 サイズ的に小さいので、Farmのパネル規格は勧めにくいんだけど、バスの規格としては、現行のAnalog2.0のライフラインがマジお薦めしやすいです。 自分でチャラから設計するのも楽しいんだけど、EIAパネルの規格とか既存の規格は、活用させていただいて、オジリナリティを発揮したい部分に注力したほうがいいよねえ。 いや、議論が必要なら、MIXIに戻すべきだけど、議論の余地なく、現行に魅力を感じるので(うっしっし、自分の都合も含めてだけど)、ここでどどーんと背中を押しておこうかなと。

返事を書く|リスト

8710	▲[8708]	なし
設計と製作 Re[3]:pARM ver2.0 開発始動（か？） #8710 gan　(2007年12月05日22時19分) takeda さん、ライフライン拡張に関するご意見ありがとうございます。 genie さんのアドバイスもおそらく趣旨は同じで、CV 増やしだすときりがないよ、ということですよねきっと。 行き掛かり上ここで議論してしまいますが（後で mixi に転載するかも）、コントロール信号を規格化する/しないの判断ポイントは、以下ですっきりさっぱりカナーと考え始めました。 - 用途のはっきりしているコントロール (CV, Gate, もしかしたらベロシティー) --> 規格化してよろしい - なんに使うかは演奏者の好みしだい (アフタータッチ、モジュレーションホイール） --> 規格化する意味があんまりない ということで、まだ思案中ですが、追加するとしてもベロシティーだけにしようかなと決めつつあります。 ちなみに、ライフラインのアイデアは Doepfer からのものですが、「つないだけど動かないよー」というユーザーさんがいらしてもサポートする余力がないと思われるので、わざと互換性なくしてます。（以下こっそり：ところが電圧はあわせてあるので変換ケーブル作れば相互接続可なはずです理論上） なんにしてもここにきて手足を止めるの非常に損失なので、細かいところはすっ飛ばしてなるたけ早くリリースできるようにがんばります。

返事を書く|リスト

8760	▲[8697]	▼[8763] ▼[8765] ▼[8925]
設計と製作 ソフトウエアEGのアルゴリズム #8760 takeda　(2007年12月21日20時54分) RJBさんがソースを公開くださってるんだけど、ちょっと難しげなんで、なんか、簡単なのねーかなと、ひねって、ブレゼンハムのアルゴリズムという、デジタルの画面に線分を描画するアルゴリズムが、ソフトウエアEGに使えるかどうか、ちょっと書いてみた。 ADSR包絡線をX軸を時間に、Y軸を出力レベルに見立てたグラフを描画してみようという狙い。 簡単に言えば、一定時間を単位時間に分割して、その時間の変わり目に出力をワンステップアップするかどうかを判断するという技法。単位時間内にしなきゃいけない演算が少なくて、ローコストなアルゴリズムかなと。線分の傾きがそのままADRのタイミングになります。アルゴリズム自体の解説はこちらに詳しい。 http://dencha.ojaru.jp/programs_07/pg_graphic_07.html 包絡線は、あくまで直線として表現。コンデンサの放電曲線とかは無視状態。 http://www.aleph.co.jp/~takeda/radio/parm/software/eg.c http://www.aleph.co.jp/~takeda/radio/parm/software/lfo.c 時間軸上に描画するグラフの線分の始点と終点のｙ座標は、0か、最大値で固定。X軸はADコンバートでえた時間の長さ。256点しかないのだから傾きの計算に必要な割り算はあらかじめやっておいてテーブル化しちゃう。上記URLの草案２というソース内の、eという変数。 もう、足し算と引き算だけ、まるでひらがなだけで書くソフトウエア、takeda向きだよね。 欠点は、最少のタイミングをそんなに早く出来ない点。割り込み周期の256倍以下にはできない。最長は結構色々作れそう。 ハードがまだないので(mega48にMIDI-CVと一緒に載せられるかなー)、基本アルゴリズムのチェックだけ、普通にCで書いてみた。適当にコンパイルしてそのまま走らせるとテキストで、出力を数字でダーっと表示するので、リダイレクトしてファイル化し、エクセルに突っ込んでグラフを描画させると動作が見える。LFOのデータはEGのまま。多分使いにくい。 このサンプルは、最少割り込みタイミングを40usとして、最短アタックタイムが10mS、最長は5s。を想定してテーブル作ってみた。数字を色々いじれば、つまみの回し具合の感じも色々つくれそう。 ただ、ちびCPUの癖にメモリー湯水のように使って大丈夫なのか？！ATTINY2313は、メモリー2kByte、ATMEGA48は4kByte.16ビットのデータ256個のテーブル二つ持っちゃったら、そんだけで1k、っちゅーか乗るのかな。MIDI-CV乗らないかも。...LFOと共存させるのは無理なのかな。なんか、実用にはならないかも..。実装目指していじってみますー。

返事を書く|リスト

8763	▲[8760]	なし
設計と製作 Re:ソフトウエアEGのアルゴリズム #8763 gan　(2007年12月21日22時32分) float 演算をして良いのでしたら、一定時間ごとに f *= alpha; /* alpha < 1 で減衰 */ で簡単にきれいな減衰曲線がかける気がしますが、素人のあさはかさ？ 整数でも精度高くすれば似たような曲線が書けると思います。 がんばって浮動小数点を実装するのも面白そうですが。

返事を書く|リスト

8765	▲[8760]	▼[8776]
設計と製作 Re:ソフトウエアEGのアルゴリズム #8765 アルゴ算法堂　(2007年12月22日13時03分) 　これ、ディスプレイに直線を描くときに、よく、お世話になるやつですね。 　傾きが４５度以内と言う制限があるので、つまり、ＸＹの長い方でステップするというものだから、常に時間軸の方向でステップするときには、余り具合が良くありません。 　固定小数点で演算して、積算のオーバーフローがうまいこと四捨五入に使えるという便利物なのですが… 　やはり、固定小数点のデルタを作っておいて、これを毎回加算する方が返って演算が楽だと思います。これなら、割り込み毎に加算するだけ。0.5の補正で丸めれば、最小精度は割り込み単位です。 　ＲＪＢさんのソースを見ていないのですが、指数的に値を戻した方が使いやすそうなので、そちらの計算が複雑になっているのではないでしょうか。 　ganさんのおっしゃるように、等比で減衰を作るのも面白いです。この場合は、速度の速い乗算が必要。 　両方とも、ＤＤＡって言っていた手法ですよね。 　規模の小さいチップで作るときは、乗算／除算の有無が、モデルの実現に関わってくるので、強い制限だし、また、ソフトを書くときの楽しみにもなります。

返事を書く|リスト

8776	▲[8765]	▼[8777]
設計と製作 ソフトウエアEGの仕様 #8776 takeda　(2007年12月26日23時46分) やっぱ、だめかー。RJBさんのをそのまま移植もあれなんだけど、いつも、おんぶに抱っこなんでココは一つオリジナルの奴までいかなくても、なんか、ちょっと違うかもなやつをAVRで、という事で、アルゴ堂さん仰る通り、固定小数点のデルタ式、なんか、やってみようかとか。 > 　これ、ディスプレイに直線を描くときに、よく、お世話になるやつですね。 ええ、馴染み深いアルゴリズムを試してみようかと。 > 　やはり、固定小数点のデルタを作っておいて、これを毎回加算する方が返って演算が楽だと思います。これなら、割り込み毎に加算するだけ。0.5の補正で丸めれば、最小精度 まさに、20年以上前に色々ご教授いただいたままのテクですね。基本は大事と...。 で、アルゴリズムはともかく、仕様をどうしようかなと。 JRBさんのCVEG(マイコンタイプ)は、「ちなみに」というタイトルで2006年08月06日に投稿いただいてる記事で発表いただいてます。 氏のブログとかその周辺の日付けをチェックすると、EGの最少タイミングは1mS以下からスタートで30秒ぐらいまで引張るらしい。 ミニムーグのパネルの写真を検索してみるとEGのアタックは最初の目盛りが10ms、最大の目盛りは10秒。ただ、これ、ツマミの1、9の位置で、それぞれ、成り行きの最速/最遅ポジションの0と10があるし、いろんなソフトシンセのカタログとか見ると、EGのアタック最速は、1mSかもなあと。 最長については、オレ様シンセ的には15秒も要らない。メロディを演奏する前提なら、5秒もあれば十分かなと。 先日の路上オフの、色々聞いたんだけど、オッショさんが、時間をかけて実際に使いながらトリミングして得たEGの最長時間は4.5秒ほど。所長君に到っては、3秒で十分とのこと。 いや、白状すると、僕も5秒ってのは、行き過ぎたオレ様仕様にならないように膨らませた数字で、気持ち的にはもう永遠に近いぐらい長い気がしてたりもする。いや、効果音に使うのなら、10秒は短いかもしれないけど、メロディ専用シンセなら4秒で十分かな？ RJBさんのソフトとの差別化の為に、EGと、LFOの出力が同時に取れるソフトってどうかなと。いうわけで、LFOのタイミング、どれくらい必要なのか考えてみた。 路上オフのとき、ブレタンさんに、「音楽のわからねえ、技術屋」呼ばわりされて、かなりカチンときたので、ちゃんと音楽に、根拠を求めて数字をだしてみようかなと。 テンポ90BPMで、全音符って0.38Hz(2.4s)。キリのいいところで、0.3Hzなら、3.33s。18pbmの四分音符。テンポ72bpmの全音符。僕の曲ではありえないテンポ200bpmの16分音符は、16Hz(36.5mS)。とりあえず、ビブラートに使うLFOとしては最高はそんなに早くなくてもいよさそうなので、仕様としては0.3Hz(3.3s)から16Hz(63.5ms)かなと。 EGは、むりとしても、せっかくなので、ブレゼンハムのアルゴリズムを生かすなら、16Hz(63.5ms)を大急ぎでステップすると(1ステップごとに出力が1段増えるとして256段だから63.5msを256で割って)248us。周期的に動かすこと考えると、行って戻って1周期だから、この半分で124us。 このタイミングをEGと共用で使えないかなと。最短を1mSとするなら、4サイクルでトップになれば、OK。最長4秒は、32258サイクル0x7E02。符号付16ビットの数字で管理できそう。 音楽的な根拠から得た数字で、ソフトウエア的にも無理なさげな仕様として、EGのタイミングは1msから4s程度、LFOは0.3Hzから16Hzまでとしてみようかな。

返事を書く|リスト

8777	▲[8776]	▼[8778]
設計と製作 Re:ソフトウエアEGの仕様 #8777 アルゴ算法堂　(2007年12月27日00時49分) 面倒なのは、ＥＧの操作そのものよりも、ＡＤＣで読んだボリュームを、うまくノンリニアに割り付ける方のようですね。 　ＥＧもＬＦＯも時間の範囲は、takedaさんのご指摘の範囲ぐらいかなと思います。 　パッチシンセ的な思考で考えるとＥＧもＬＦＯも、標準的にVCO/VCF/VCAに使うだけでなくて、他の使い方があるから、特に長い方は範囲が広いほうが嬉しいんだけれど…。 　ＬＦＯでステップシーケンサを動かしたり、フレーズ全体にＥＧをかけたりとか…

返事を書く|リスト

8778	▲[8777]	▼[8812]
設計と製作 Re[2]:ソフトウエアEGの仕様 #8778 takeda　(2007年12月27日21時32分) LFOのテーブルレスアルゴリズム検討 フォローいただくと、心強いな。とりあえず、試行錯誤の最初のポイントはココっちゅーことで。上手くいけばラッキーだし。必要なら、また、変更と...。 RJBさんのソフトが30秒程度に対応との事だし、氏のソフトとは違うなんかとして公開するのが狙いなんで、一応なんか差別化しなくちゃと、短めのをやってみますね。 仕様は0.3Hzから16Hzとすると51倍の変化。最小単位時間を124usとすると256段ステップを往復して16Hz(63.5ms)。この時の変化の傾きは1。傾きが1/51になれば、0.3Hzぐらいになる。 5/5=1とすると、5/255が1/51と同値と考える（正規化されて無い傾きで考える）ADコンバーターの1段の変化で、0.2ずつ、もとの周波数から変わるという感じ。 ADコンバーターで得られる数字は0-255のつもりで、これが、分母になるというわけ。(本当は分母は、5-255の変化で無きゃいけないんだけど、5以下は１としてみても、250段階の変化が表現できるし、0V周辺や5Vは誤差で思う数字が出ないとすると遊びが必要かもとかいいつつ逃げたりして。）5以下なら5にしちゃう方向で、特にコンバートしないで0-255のままでいけそう。 で、仰る通り、そのまま、ADCの変化を指数カーブへの変換がむずかしそうです。使い道は多そうだから、代表的な係数のテーブルとして使いまわせるかなと、エクセルでいろんなカーブを表示して見ましたー。 http://www.aleph.co.jp/~takeda/radio/parm/work/exp-curve.gif http://www.aleph.co.jp/~takeda/radio/parm/work/exp-curve.xls これまで、集めたデータのチェックで、指数的な変化かどうかとか、みた経験はあるんだけど、自分で、EXPカーブを造ろうと思ったのは、実は初めて。ぽりぽり。 数表の部分は単純に、y=exp(x)としただけの数字をグラフ化したもの。、Y軸の変化を0-1、0-10、0-50、0-100（それぞれ、青、赤、黄色、空色）のグラフの形を正規化してみると見た目で全然形が違う。えー。(直線のグラフは、それぞれ、Y軸を対数目盛りにしたもの） いまさらなんだけど...どのカーブを使えばいいんだろ。 1から51倍までかわるのだから、0-50のカーブが正解なのだとすると、いろんな値で使える便利な係数のテーブルってのはありえないのかな。 ChuckさんのLFOのソフト、スピードのとりだしのところカーブつけてるって仰ってたから、見直してみよう....。

返事を書く|リスト

8812	▲[8778]	▼[8814] ▼[8815]
設計と製作 指数変換 #8812 takeda　(2008年01月07日19時37分) Chackさんのソースを拝見しながら色々Wikiペディアとかで勉強したり、やすださんがご紹介くださった http://www.musicdsp.org/showmany.php のなかから Exponential parameter mapping http://www.musicdsp.org/showone.php?id=87 を参考に色々勉強してます。 ロボット関係とか、モーターの回転数とかで、似たような計算をやってる方多いはずなんで、ちゃんとアルゴリズムを書いておくのもあれかなとか、いいわけくさいけど、マジ勉強中です、勘違いとかありましたら、ご教授いただければ幸いです。 速攻で必要な結論へ飛びつかず、どう、底へ到るかなアルゴリズムをちゃんと明らかにしとけば、幾らでもバリエーションが得られそうだという、3歩進んで5歩下がる式。 それはともかく、上記の Exponential parameter mapping　、 float logmax = log10f( mMax ); float logmin = log10f( mMin ); は、乗数の範囲を求めるもので、昨年末のエクセルのカーブをで言うところの1倍のカーブなのか、50倍のカーブなのかを決める計算なので、たとえば、EGとかの時間設定なら、固定の定数になりますから、あらかじめ定数で用意すればOK。毎回やらなきゃいけない計算は、 float logdata = (mParam * (logmax-logmin)) + logmin; mData = powf( 10.0f, logdata ); の２つ。最初のは普通に掛け算。mDataは、logmax 、logminを10を底としたから、10の何とか乗。logmax 、logminを自然対数でとれば、ここは、2.718の何とか乗でもOK。 たとえば、LFOのタイミングの設定として、最低を0.3Hz最長を16Hzとして、最低時間が何倍になれば、最長になるかを計算すると53.3倍。（ここは単純に割り算） ブレゼンハムで計算するとして、傾きが53.3/53.3(要するに1だけど)から、1/53.3まで変化すればOK。1と、53.3の自然対数はそれぞれ、0と3.976。これが、2.718の乗数として0から3.976までリニアに変化する値を突っ込むと、1から53.3までで出てくる数列が、いま求めてるカーブのついたデータになりそう。 で問題は、2.718の3.976乗。小数点の乗算が面倒だぞと。たとえば、1.5乗なら、浮動小数点ライブラリがあれば、 pow(2.718, 1.5);　または、exp(1.5); perlなら、 2.718 ** 1.5 Chackさんの計算法は、1.5という乗数をばらして、2.718の1乗X2.718の0.5乗とする。 http://www.kdcnet.ac.jp/college/buturi/kougi/suugaku/zennki/exp1/exp1.htm の「指数法則」参照。ちなみに、2.718の3.5乗は、(2.718の1乗)の3乗X(2.718の0.5乗)。 ってのが、実数での計算の話で、手元の8bitのちびCPUにどうインプリメントするか、がもう1ひねり。 まず、計算全体の底を10とか2.718じゃなくて2にしても同じ結果がえられそうだぞと。で、小数点のついた面倒な乗算部分はテーブルから引っ張っちゃう。あとは整数乗だから普通に掛け算すればOK。逆に言えば、テーブルで持たなきゃいけないのは、0から1までの小数点の部分だけで済む。さらに、底が2なら掛け算、シフト計算でいけそーだぞと。 http://www.kdcnet.ac.jp/college/buturi/kougi/suugaku/zennki/log1/log1.html の「◆対数の性質」4番で手元の処理系の対数の関数の底が何であっても2を低とした対数が得られそうです。

返事を書く|リスト

8814	▲[8812]	なし
設計と製作 指数変換実装編part1 #8814 takeda　(2008年01月07日19時41分) 指数変換実装編part1 ブレゼンハムのアルゴリズムで計算するLFOの場合(0.3Hzから16Hz)： 指数変換の出力として要求される数字は、直線のかたむきの数字の分母。53.3/53.3から、1/53.3。コレを、255/255から5/255と変形させて、255から5までの間で指数で変化する値が取れればよさげ。 2を底とする5の対数はエクセルなら "=LOG(5)/LOG(2)"で計算できて2.3219。255は、8ぐらい。対数変換の入力として、2.32から8までリニアに変化が必要。 さて、入力は、AD変換で得る0から255までのリニアな変化。これを、2.32から8までの範囲で変化する値に変換してさらに、このリニアな変化を指数変換に突っ込めば5から255までの指数変化する数列が得られると。 入力の範囲が0から255と決まっていて、変換が2回重なるのなら、あらかじめ変換した値を256個、もっときゃ良いじゃん、が、テーブルメソッド。 で、perlで書いたテーブル生成スクリプトがこちら。 http://www.aleph.co.jp/~takeda/radio/parm/software/GetExpTable4LFO.pl 前半が、エクセルに突っ込んでカーブをグラフで見るためのデータ、後半は、プログラムに突っ込むように整数化（って、四捨五入だけど)したもの。 作ったエクセルデータがこちら。最近、やっとopenofficeを使い始めて、エクセル、怖くなくなったー。 http://www.aleph.co.jp/~takeda/radio/parm/software/exp-table4LFO.xls このデータをもとに、テーブルメソッドで指数変換を実装した(ちょっとマトモに動きそうな)ベルゼンハム式LFOのアルゴリズム。 http://www.aleph.co.jp/~takeda/radio/parm/software/lfo2.c 実際にpicや、atmelに載せるにはそっちの初期化が必要。124usごとに呼び出す。 テーブルメソッドの良い点は計算コストが殆ど無し。欠点は、メモリーを湯水のように使っちゃう点。チビCPUには、きつい。

返事を書く|リスト

8815	▲[8812]	▼[8816]
設計と製作 Re:指数変換 #8815 RJB　(2008年01月07日22時39分) こういう組み込み用途っぽい数値演算アルゴリズムは、いろいろと隠れたノウハウ（職人技？）があるようですね。 普段、パソコン上でやっていると深く考えずにmathライブラリを使いますけど、このようなタイミング的に制約がある場合には、すぐ割り込みインターバルを超えちゃったりするので、おいそれとは使えないですしね… >まず、計算全体の底を10とか2.718じゃなくて2にしても同じ結果がえられそうだぞと。で、小数点のついた面倒な乗算部分はテーブルから引っ張っちゃう。 仰る対数演算法はAVRのテルミン型コントローラを作ったときに使いました。ただし、テーブルじゃなくて直線近似にしましたけど、感覚的にはテーブルでも直線近似でもほとんど差がありませんでした。 http://www.rjblog.net/archives/2007/e000268.php ちなみに、このとき参考にしたのはなひたふさんのブログで紹介されていたものです。 http://nahitafu.cocolog-nifty.com/nahitafu/2006/11/fpga_04ab.html

返事を書く|リスト

8816	▲[8815]	▼[8817]
設計と製作 Re[2]:指数変換 #8816 takeda　(2008年01月08日02時23分) > 仰る対数演算法はAVRのテルミン型コントローラを作ったときに使いました。ただし、テーブルじゃなくて直線近似にしましたけど、感覚的にはテーブルでも直線近似でもほとんど差がありませんでした。 > http://www.rjblog.net/archives/2007/e000268.php はー、しまつた。ビデオ拝見してステキーとか叫んだままソース見るの忘れてました。申し訳ない早速掘って見ます。 まだ、ちゃんと理解できてないけど、今回用意しようとしてるカーブって、昨年末かいてみたグラフ http://www.aleph.co.jp/~takeda/radio/parm/work/exp-curve.gif のうち、一番まがってんのかどーかよくわかんない青のカーブですよね。ちゃんと曲がってるよーにはみえねえから、まっすぐでやっちゃえよ、っちゅーことですね。うにゃ、なるほどって感じです。 とりあえず、ソースのほうちゃんと見てからまたアレしますー。 あと、「職人技」に触発されたにちがいない、PCM1723さんの、ブログ「シンセ・アンプラグド」のほうでも「指数関数の近似式」が紹介されてます。 http://d.hatena.ne.jp/pcm1723/20080107#seeall 遠くからの援護射撃に感謝ー。 (去年の12月の頭から、スタートされたイカしたタイトルのブログ。ものすごい勢いです。半年ぐらい書き溜めたネタを少しずつ公開されてるに違いないと思うような濃いネタが毎日掲載されてて、おっしょさんとの間では、保存版指定になってて、あまりに濃すぎて、フォロー入れにくいんですが、毎晩どきどきしながら拝見してますー！、ネタを提供できたみたいな気がしてちょっとうれしーっすー。というか、フォローありがとうございます。色々勉強しますー。 あ、そうだ、外部リンクの図面の類が見られないんです。フリッカーのIDか何かとらないと見られないのかしら、フォロー入れなきゃと思いつつ...遅くなっちゃった）

返事を書く|リスト

8817	▲[8816]	▼[8846]
設計と製作 Re[3]:指数変換 #8817 pcm1723　(2008年01月09日00時08分) > あ、そうだ、外部リンクの図面の類が見られないんです。フリッカーのIDか何かとらないと見られないのかしら、フォロー入れなきゃと思いつつ...遅くなっちゃった） 当初の一週間くらいはプライベートモードで書いていて、後にパブリックにしたのですが、その時に「はてなフォトライフ」の設定をパブリックにするのを忘れていて、本人以外見えない状態になっていました。 現在はパブリックの設定になっていますから、以前見えなかった図も、今は見えるようになっているはずです。 記事をストックしておける余裕があればいいのですが、当日の記事は当日書くという状態で、全く余裕がありません。 ついでなので、しばらく EG についての記事を書くことにしました。

返事を書く|リスト

8846	▲[8817]	なし
設計と製作 MIDI-CVのピッチベンドの処理 #8846 takeda　(2008年02月08日21時38分) pcm1723さんのシンセ・アンプラグド http://d.hatena.ne.jp/pcm1723/ もう、こちとらビデオとか作って遊んでるうちに淡々と進まれて、毎日ドキドキしながら拝見してる割には、質問とかフォローとか書くスキが無いー とかｍ嘆いてないで、pARM専用のMIDI-CVのアルゴリズム考えなきゃと..。 基本的には、RJBさん/アルゴ堂さんのMIDI-CVをAVRのCで（書き換えやすいソースつき）がねらい。追加で、EGやLFOも入れたいとか、アルゴ堂さんみたいに、豪華にパラメーター盛り込めればあれだけど、先ずは基本形を押さえておこうかなと。というわけで、先ずは基本機能としてMIDI-CVやらなきゃなと。で、ベンドの処理、RJBさんのソースをハック！ ベンドホイルからのMIDI-DATA、MIDIキーボードからは、7ビットずつ2回に分けて合計14バイト分取れるんだけど、とりあえず、上位だけ利用することにして、始めに届く下位分は捨て、後から届く上位7ビット分使うことにする。 センターが64で、最大が128、最少が0。64以下はマイナス(音程が下がる)だけど、面倒なので、一番最後にセンターの値をつじつま合わせて引いとゃいいか戦略。ゼロ以下になったら0にする。 AVRのPWM、10ビットの解像度が取れれば、MIDI-NOTEは、128段階、7ビットなので、固定小数点を、3ビット目にできそう。この系で1は、4ビット目なので、8。 例えばホイルをめいっぱいぶち上げると128というデータがくるとして、ベンド幅は2なら、ベンドの上下で操作できる音程は、上下合わせて4音。8X4で32。ホイルのデータの128を32に変換できればいいわけだ。（これにかぎれば、シフトでいけるねえ） keyノートは、この固定小数点の系では常に整数部分だから、3ビット右にシフトすればできあがり。これと、ベンドの量を足し算して、最後につじつま合わせでベンド最大幅の半分の量(この場合8X2の16)を引けばOKかしら。 やるかどうかはともかくとして、ビブラート用のLFOのデータも最後にセンターの値を引き算でいけそうな気がする。 ChackさんのソースのPWMの値をセットするマクロをこの変換する関数に書き換えればいけるかなと。 pcm1723さん、ポルタメントの処理もソフトで（というか何もかも全部だけど)実装されてて、真似しようか、ちょっと悩むところだけど...って、書けるかどうかは又別だけど。

返事を書く|リスト

8925	▲[8760]	▼[8927]
設計と製作 ソフトウエアEG再挑戦！ #8925 takeda　(2008年05月01日23時30分) 以前、RJBさんがご紹介くださった、PWMをつかった8pinDIPの1-chip EG http://www.rjblog.net/archives/2005/m200512.php ご本人のBlogではソースは未公開。当掲示板にだけ、こっそり公開くださってるのがこちら。 http://analog-synth.jp/cgi/dkb_as/dkbsystem.cgi?id=&md=viw&no=7005&tn=6981 AVRに移植しようと色々検討したんだけど、PICの10bit幅のPWMを使われてて、AVRの8pinDIPなTiny45では、まま移植は無理なのかな。 ソースの中に、10bitの1023とか出てくるし、わからないなりに考えると、やっぱ、最大値が1024と255ではテーブルのつくりも変わるんだろうなあとか...。（あ、出力は１箇所にまとまってるから、ここで、２bitハショりゃいいのか..今、気がついちゃった..） どちらにしても、タイミングとか独自のものがほしい場合にはテーブルを差し替えないとだめ。で、プログラム読み込んでるんだけど、自前で書けそうな気もしてきたり来なかったり。ちょっとむずかしーっすね。RJBさんのソースは参考にさせていただきつつも、色々ソフトが公開されてるのはいいことに違いない、と、別のを書いてみようかと...。普通にメロディーを演奏するのに使いやすいパフォーマンスモードのソフトウエアEGとして、ADSRで、1mS〜3sかなと。Tiny45の8MHｚで走らせて、PWMは10k弱って感じ。かけるかなー。 指数の計算、整数だけでできるようになったので大喜びでエクセルで色々グラフかいてみたりして。 1mS〜3sをADコンバーターの255でコントロールすると、テンポ120で四分音符ひとつ分(500ms)のタイミングが、ADコンバーターの200弱相当。つまみの位置的には、7.8。センターにすると、50ms。テンポ120で1/32音符が62.5mSぐらい。これって、どーなんだろ。使いやすいカーブになるのかちょっと不安になってきたー。 先日公開した、スピードのろくて使い物にならないかもよ版、 http://www.aleph.co.jp/~takeda/radio/parm/software/eg.c を書き換えてみようかなと。LFOのほうは、波形も三角、鋸、逆鋸、矩形波と4種類つけて、リリース準備中。先にアルゴ堂さんの「蛙計画」 http://homepage2.nifty.com/sampodo/ 「アルゴ算法堂のＨＰ」-「電子工作」-「ＰＩＣピコピコ」に痛く感銘して、ついでに、Analog2.0支援、ミニキーボードをやります、chuckさんのCV-冶具 http://emusic.g.hatena.ne.jp/Chuck/20060102/p1 のバリエーションとでも言うか..なんてなこといってるうちに、RJBさんが、「pARM type-R」を発表されてたりして。 http://www.rjblog.net/archives/2008/e000297.php たいしょーってば、手が早いからー！いや遅れを取った！MIDI-CVにLFOを突っ込もうと僕も準備してたのにー！。しょうがないからEGも突っ込まなきゃだわ。秋月でRJBさんが使われた、Mega88が250円で手に入るようです。僕も2発、手にいれてあります。容量足りるかしらー。

返事を書く|リスト

8927	▲[8925]	なし
設計と製作 Re:ソフトウエアEG再挑戦！ #8927 RJB　(2008年05月01日23時56分) > 以前、RJBさんがご紹介くださった、PWMをつかった8pinDIPの1-chip EG きちんと整理していないので、後から自分でみても何が何だか…(^_^;) > たいしょーってば、手が早いからー！いや遅れを取った！ そんなことはー（笑） それぞれいろんなアプローチがあってもいいと思いますので、ひとつの参考ということで… >Mega88が250円で手に入るようです。僕も2発、手にいれてあります。容量足りるかしらー。 Mega88ホントお得ですよねー 容量はたぶん余裕で入ると思いますよ。