■タグ「PureData」

■RasPd4 ハードウェア編

03_213_1raspd4p.jpg
微妙に不安定な面があったRasPd2を作り直しました。「3」を飛ばして「4」になっていますが、奇数番号は多機能タイプで、偶数番号はコンパクトタイプということにしておきます。スイッチやポットの基板についてはRasPd2のものを流用しており、外観は変わりません。初めてPCBを基板製造業者に注文しましたが、まぁまぁ納得の出来栄えでした。Raspberry Piは「zero W」です。

▽回路図
03_213_2raspd4s.png
入力にローパスフィルターを追加し、出力はヘッドフォン出力ではなくライン出力を使っています。ステレオ入力や出力バッファー追加も考えていたのですが、チップ部品でないと入らなさそうだったので諦めました。ダンピング抵抗は22Ωから47Ωへ上げて様子を見てみます。電源は9Vではなく5Vにしたので、大きな降圧レギュレータが不要となりました。DCジャックには間違えて9Vのプラグを挿さないように、秋月電子で買った「電圧区分4」というものを使用しています。

▽レイアウト(KiCadのデータはこちらへ)
03_213_3raspd4l.png
あまり意味はないかと思いますが、一応レイアウトも載せておきます。GNDはアナログ(右側)とデジタル(左側)に分けていて、中央下のあたりの一点で接続するようにしました。GPIOの番号は「*」印で示しており、使わないGPIOについては左端に引き出してあります。Raspberry Piが重なる部分は高さ7mmの電解コンデンサを使いましたが、スペースがあるので横に倒してもなんとか入りそうです。注文した基板は1M(R1)と1K(R2)の印字位置を逆にするというミスがあり、危ないところでした…

ノイズについてはRasPd2とほぼ同じくらいです。ギターが拾うノイズの方が大きいので、まぁOKということにしておきます。最大入出力レベルは0.9Vrms程度で、これも問題ないと思います。以前あったエラー音のような音については、起動して数十秒の間に短くビッと鳴ることがありますが、それ以外では今のところ大丈夫なようです。

WM8731より性能がよいIC(CS4272が候補)を使うとさらに高品質になると思われます。自作するとなると情報が少ないのですが、今後取り組んでみたいところです。

■オーバードライブ(Pure Data パッチ)

デジタルの歪みはなかなか自然な感じにするのが難しく、自分なりにいろいろと検討しました。詳細は前回の記事(真空管風デジタル歪み)をご覧ください。
03p_211_1od.pngこのパッチをダウンロード
gain1では二次関数 f(x) = x2 + x を使い、波形を非対称に変形させて浅い歪みを調整します。ただそのままでは x < -0.5 のとき波形が折りたたまれる形になるため、[clip~ -0.5 100]を入れてそれを防いでいます。gain2は[tanh~]を使った対称ソフトクリップで、深い歪みを調整します。

個人的に便利かなと思い組み込んだのが、右側に配置している音量調節機能です。弾きながらadjust_vol(フットスイッチを想定)を押すと、エフェクト音の音量が原音と同じになるように変更されます。原理は簡単で、原音とエフェクト音それぞれに繋がっている[env~ 32768](左上と左下のあたりに配置)から出力される値の差を計算するだけです。

トーン調整についてはとりあえず単純なハイパスフィルターとローパスフィルターにしていますが、私の感覚には結構合っている調整方法のようです。デジタルなので内容の変更や追加は簡単にできます。気が向いたらクリーンミックスやフェンダー型トーン回路等いろいろ試してみたいと思います。

■タグ : 歪み PureData

■コンプレッサー(Pure Data パッチ)

Pure Data(Pd)では[limiter~]でコンプレッサーを作ることができます(zexyが必要)。自分で作ってもそこまで複雑ではありませんが、今回はニー(knee)というコントロールを追加していますので、やや大掛かりなパッチとなっています。
03p_206_1comp.png
このパッチをダウンロード
[env~ 256]は128サンプルごとに値を出力するため、[delwrite~]で原音をその時間分遅延させてタイミングを合わせています(Windows環境ではなぜかさらに64サンプル程度タイミングがずれました)。[env~]を使ったエフェクト全てに行うべき処理ですが、ディレイタイムがそのままレイテンシーの増加になってしまうため、ノイズゲートオートワウでは省きました。

[env~ 256]からのエンベロープデータは2つの[moses]で3パターンに振り分けます。threshold+kneeの値以上では通常の圧縮動作となり、threshold-kneeの値未満では圧縮がかかりません。真ん中下側と右側の[expr]の式がコンプレッサーの定義的な式となります。
(例)入力:80dB、threshold:60dB、ratio:10のとき
   →( 80 - 60 )÷10 + 60 - 80 = -18 (入力音を-18dB変化させる)

threshold±kneeの範囲では、滑らかにthresholdを変化させます。どういった曲線にするかですが、下図のような楕円を考えました。参考ページ→平行四辺形に内接する楕円の三種
03p_206_2comk.png
k=0のときは急に折れ曲がる形(ハードニー)で、kを上げていく程なだらかなカーブ(ソフトニー)になります。市販のコンプレッサーではどのように処理しているかわからないので、完全に自己流です。

attackとreleaseは音量変化にかける時間(ms)を指定します。[env~]からはデータが次々と出力されてくるので、音量変化の最中にまた次の音量変化に切り替えることになります。このため、実際の変化時間は指定した時間よりも長くかかりますが、動作の仕方としてはそれで問題ないようです。参考ページ→コンプレッサーを考える コンプレッサー アタックタイムの真実 (各種コンプ比較あり)

コンプレッサーの世界は思っていたより奥が深く、入出力の関係がもっと複雑なカーブになっていたり、周波数によって特性が違ったりするものがあるようです。まぁ私には大して違いがわからないでしょうから、あまり深追いしないことにします。

■ノイズゲート(Pure Data パッチ)

Pure Data(Pd)には[threshold~]という音の始まり(立ち上がり、trigger)と終わり(立ち下がり?、rest)を検出できる便利なオブジェクトがあります。これを使うと簡単にノイズゲートを作れると思ったのですが、音声信号をそのままつなぐとtriggerとrestが頻繁に入れ替わってしまいます。この現象はおそらく[threshold~]の内部処理がエンベロープ検出になっていないために起こっているので、[env~]を入れることで対処できます。ただ更に検討していくと、[threshold~]は64サンプル分余計に処理時間がかかってしまう場合があることがわかったため、結局[env~]と[moses]でノイズゲートを作ることにしました。
03p_205_1noiseg.pngこのパッチをダウンロード
threshold以上になった信号は[moses]により右側に送られ、[change]でtriggerを検出します。検出後、左側の[change]に[set 0]が送られrestの受付を開始しますが、同時に左側の[spigot]が一定時間閉じられるため、restをすぐには検出しないようになっています。これによりtriggerとrestの短時間での繰り返しが防げます。threshold未満のときは左側に信号が送られ、同様のことが起こります。

立ち上がり時間(attack)はできるだけ短くしたいのですが、0にするとプチッというノイズが発生することがあるため、とりあえず0.1msというごく短い設定です。立ち下がり時間(decay)は500msと長い設定なのでノイズ遮断のキレが悪いですが、音の消え際を自然にするためにはやむを得ないでしょう。

(※パッチ内容を把握しきれていませんが、Isaac(139)さんのノイズゲートの方が高機能だと思います。→139 not found [Puredata]Noise Gate

バックグラウンドのノイズを消すという機能は、[rfft~]を使って周波数解析すれば実現できるかもしれません。しかしCPU負荷と処理時間の問題があるため、難しいだろうと思います。

■タグ : PureData

■オートワウ(Pure Data パッチ)

[env~](エンベロープフォロワー)を使って音量データを取得し、それに応じてバンドパスフィルター(BPF)の中心周波数が変わるようにすれば、オートワウ(エンベロープフィルター)となります。中心周波数を揺らす場合のBPFは[vcf~]を使いますが、Q値が基本的に固定値となります。ペダルワウは中心周波数が高い時(ペダルを閉じたとき)Q値が小さくなりますが、そこまで再現しなくてもワウっぽい音にはなるようです。
03p_204_1awah.pngこのパッチをダウンロード
rangeコントロールは、中心周波数が最高(2200Hz)になる時と最低(440Hz)になる時の音量差を調整します。rangeが小さい方が、音量減衰時に周波数の変化が急(速くこもる)ということになります。

滑らかに中心周波数を変化させるため、周波数と変化にかける時間の数値を[pack]でまとめて[line~]に送ります。[env~ 1024]からは512サンプルごとに数値が出力されるため、変化にかける時間は、512÷44100で約12msという計算となります(44100サンプル時)。

LFOやタップテンポを入れ、周期的にワウをかけることも可能です。ただデジタルだからといって多機能にしすぎると、CPU負荷の問題が出てくるかもしれないので、シンプルな構成にしています。

管理人

ブログ内検索

メールフォーム

当ブログに関するお問い合わせはこちらからお願いします。 ※FAQ(よくある質問)もお読みください。

お名前
メールアドレス
件名
本文

アクセスカウンター