g200kg Music & Software

これまでに ADSR 関係の記事を幾つか書いてきたのだけど、ADSR についてはまだ言いたい事があるのだ。あなたの ADSR の実装、間違ってないだろうか? と。ADSR はシンセを構成するモジュールとしては簡単な方だし、ソフトウェアで実現するのもそれほど難しくはない。が、ここで説明する点は特に勘違いしやすいので注意して欲しい。

ADSR はざっくりと下の図のような説明がされている事が多い。ADSR の概要を説明するにはこれで問題はないのだけど、この図を見て、「完全に理解した。アタックのピークを過ぎた後は、減衰の曲線が Key On の間は Decay で Key Off になると Release に切り替わるんだね」と言う風に理解してしまうとまずい事になる。

次のような設定にした時を考えてみる。
Decay ⇒ 小、Release ⇒ 大、Sustain ⇒ 小。

音の出始めにガツンと強いピークがあり、そのまま消えるのではなく、その後も薄く鳴り続けリリースの消え際も長い、という感じの音だ。これでアタックのピーク近くの瞬間にキーを離してしまったらどうなるか...。

「Key Off になるとディケイからリリースに切り替わる」だと、緑の線のようになりますよね。これに違和感があるのは明らかでしょう。アタックの一瞬だけのはずだった音量でしばらく鳴り続けるのだから。
正解は次の図

紫の線のように KeyOff の後、Sustain レベルまでは Decay の速さ + Release の速さで減衰しないといけない (減衰は漸近線なので、Decay の減衰カーブだけの場合は Sustain レベルに辿り着けないのはわかると思う)。

また Attack のピークに至る以前に Key Off が発生した場合も同様で、次の図のように Key Off 時点の現在値が Sustain レベルより高い間は Decay の減衰 + Release の減衰、現在値が Sustain レベル以下ならば Release の減衰が適用される。

つまり Decay の減衰の発動条件は、
　「Attack フェーズ以外で、現在の値が Sustain レベルより高い時」であり、
Release の減衰の発動条件は
　「Attack フェーズ以外で、現在のキーの状態が Off の時」なのだ。
そしてこの二つの減衰は重なり合う事もある。
また Attack フェーズとは、
　「Key On でトリガーされてから現在値を増加させて行き、ピーク値に到達する、または Key Off になるまで」である。



if( detectKeyPositiveEdge )
    AttackPhase = true
if( CurrentValue >= PeakLevel or Key == OFF )
    AttackPhase = false
if( AttackPhase ){
    increase CurrentValue by AttackRate
}
else{
    if( CurrentValue > SustainLevel )
        decrease CurrentValue by DecayRate
    if( Key == OFF )
        decrease CurrentValue by ReleaseRate
}

これだけの事で以前書いたリトリガーの問題も解決する　(そして残念な事に、このように現在の値を基に曲線をトリガーしたり、複数の減衰曲線を重ねたりしようとすると Web Audio API のオートメーション関数ではとても面倒な事になるのだ)。

ハードウェアで作る時は大体参考にする公開された回路図通りに作る事から始めるケースが多いので間違える事は少ないのだが、ソフトウェアでは最初の ADSR の波形を見ながらスクラッチから自分で実装しようとして失敗する場合があるので気を付けて欲しい。

Posted by g200kg : 9:31 PM : PermaLink

2020/07/08 (2020年07月のアーカイブ)

新しいWebSynthを作ってみた (WebGrowler)

先日 AudioWorklet で ADSR を出力するノードを作ったのですが、これまでに他にも楽器系に使える各種ライブラリを作ってきたのでそのあたりを全部まとめて使ってみようか、という事で作ってみました。

WebGrowler という名前です。コンセプトとしては、「適当にツマミをいじってもそれなりに派手な音がする」です。audioworklet-adsrnode は ADSR をノードの出力として出せますので、音信号だけでなく制御系信号をノード間の connect() で処理できるのが特長です。これを活かすためにエンベロープと LFO をソースとする大き目のモジュレーションマトリックスを付けてあります。

使用しているライブラリは次のとおりで、どれも GitHub に置いてあります。

webaudio-controls : 楽器系 GUI パーツライブラリ

webaudio-pianoroll : ピアノロール表示ライブラリ

webaudio-macronodes : Web Audio API のノードとして動作する各種エフェクターライブラリ

audioworklet-adsrnode : ADSR カーブを出力する audioworklet ノード

GitHub Repository : https://github.com/g200kg/webgrowler

デモページ : https://g200kg.github.io/webgrowler/demo.html

Posted by g200kg : 2:15 PM : PermaLink

2020/07/04 (2020年07月のアーカイブ)

デノーマル問題は今どうなっているのか

もう今から 10 年近く前の話になりますが、ソフトシンセ等の楽器系ソフトウェアではデノーマル問題というのがちらほらと起こっていました。これは扱うデータが通常の浮動小数点では表現できないほど小さい ( 0 に近い) 状態になると、単に 0 に切り捨てるのではなくて CPU がデノーマルモードという特殊なモードで近似的に扱う代わりにパフォーマンスが極端に悪い状態になる事を指します。

ソフトウェアのジャンルによってはこれでも特に問題はなかったのですが、楽器系ソフトウェアはリアルタイム処理が命で処理が間に合わないとノイズが発生する等の結果になったりしますので特に敏感だったわけです。そしてこの問題はネイティブアプリだけではなく、Javascript 上でも同じように存在していて Web アプリでシンセを作ろうとするとやはり気にしないといけなった、というのが大体 9 年前。↓の記事でブラウザ上のデノーマル問題について少し検証しています。

「Javascriptでもデノーマル問題はあるんだよ!」

その後、Chrome のバグトラッカーにこの問題があがって対策されたのが 5、6年前くらい。これでもう Web アプリでデノーマルに悩まされる事は無くなるのかなー、やったね。
という事があって、もうデノーマル問題の存在すら忘れかけていたのですが、今になってちょっと引っかかった問題をきっかけにこのあたりを掘って見ると、見つけてしまいました。デノーマル再来。

問題は TypedArray です。

倍精度の場合は
\( 2.22 \times 10 ^{-308} \)、

単精度の場合は
\( 1.17 \times 10 ^{-38} \)

あたりよりも 0 に近くなるとデノーマルモードに入ります。Javascript の通常の変数の場合はすべて倍精度浮動小数点として扱われ、10のマイナス308乗あたりよりも小さくなるとデノーマル状態になりますが、どうやら何らかの対策が行われていて特にパフォーマンスが落ちるという事はないように見えます。しかし、これが TypedArray、Float32Array や Float64Array の場合は、昔のようにデノーマル状態でパフォーマンスが 5～6 倍程度落ちるようです ~~(昔よりはパフォーマンスのペナルティは低くなっているようですが)~~。

下に検証用のコードがあります。javascript の通常の変数、Float32Array、Float64Array についてそれぞれ変数の値に 0.1 を掛けて行き、時間を測定しています。
これをそのまま Javascript コンソールに貼り付ければ実際に結果を見る事ができます。


for (f = 0.1; f != 0; f *= 0.1) {
  Time1 = performance.now();
  for (var i = 0; i < 1000000; ++i) {
      result = f * 0.1;
  }
  Time2 = performance.now();
  document.write((Time2 - Time1)+"mSec , "+result+"<br/>");
}
document.write("Loop Exit!! (Normal Variable) <hr/>");

a=new Float32Array(3);

for (a[0] = 0.1,a[1] = 0.1; a[0] != 0; a[0] *= a[1]) {

  Time1 = performance.now();

  for (var i = 0; i < 1000000; ++i) {

      a[2] = a[0] * a[1];

  }

  Time2 = performance.now();

  document.write((Time2 - Time1)+"mSec , "+a[2]+"<br/>");

}

document.write("Loop Exit!! (Float32Array) <hr/>");

b=new Float64Array(3);

for (b[0] = 0.1, b[1]=0.1; b[0] != 0; b[0] *= b[1]) {

  Time1 = performance.now();

  for (var i = 0; i < 1000000; ++i) {

      b[2] = b[0] * b[1];

  }

  Time2 = performance.now();

  document.write((Time2 - Time1)+"mSec , "+b[2]+"<br/>");

}

document.write("Loop Exit!! (Float64Array) <hr/>");

さて、この結果は下の図のようになりました。左側が通常の変数の場合です。デノーマル領域を超えて 0 になるまで特に処理時間に変わりはないようです。しかし、

右側上 Float32Array の場合は \(1.17 \times 10^{-38}\)
右側下 Float64Array の場合は　\(2.22 \times 10^{-308}\)

よりも小さいデノーマル領域では処理時間が落ちているのがわかります。

昔みたいに何十倍も遅くなるという程ではないので致命的な問題にはなりにくそうではありますが、逆に、パフォーマンスいまいちだなーとか思いながら気が付かずに使ってしまうという事がありそうですね。 TypedArray を使う時には気を付けた方が良さそうです。

-----(2020/07/04) さっそく追記ですが-----

昔よりデノーマルのペナルティが低くて 5～6 倍というのは勘違いだったようです。事態はもっと深刻とも言えます。
という事で検証用の式と結果を訂正します。

検証で使用した計算式が元は、通常の変数 = Float32Array * 通常の変数になっていました。
この場合、通常の変数にデノーマル数をロードするのが遅いという事はわかりますが演算自体はデノーマルのペナルティが発生しない通常変数で行われています。

Float32Array = Float32Array * Float32Array のように TypedArray のままで演算自体が完結する場合、デノーマル数が発生すると通常の場合よりも 20 倍程度時間がかかるようです。

ただし、TypedArray の演算は通常の変数よりも高速ですのでそれに比べて、という話になります。高速なはずの TypedArray なのにデノーマルを発生させてしまうと通常の変数よりも遅くなってしまうという事でもあります。TypedArray を使う場合は十分に注意する必要がありますね。
なお、この件は Chrome、Firefox 共同じ現象になるようです。

Posted by g200kg : 11:47 AM : PermaLink

2020/06/30 (2020年06月のアーカイブ)

Web Audio API での ADSRカーブその2 audioworklet-adsrnode

さて、前回 Web Audio API のオーメーション関数で ADSR のリトリガーの挙動を実現する際に問題があると書いたのですが、書き忘れてました。これが問題になるのは「モノフォニックシンセ」の場合です。

和音が出せるポリフォニックシンセの場合は当然エンベロープジェネレータ自体もボイス数分確保されていますので、打鍵ごとに今空いているエンベロープジェネレータがアサインされるため、無視できないほどの現在値を持った ADSR をリトリガーしなくてはならない状態が発生するという事は根本的にボイス数が足りないという事になります。ま、リリースをやたら長く設定した場合なんかは割と簡単にそういう状態が発生したりもするので無関係というわけでもないですが。

とにかく、このオートメーション関数による ADSR カーブの生成については私も色々試行錯誤はしたのですが、結論から言うと...面倒くさくなって諦めました。そうじゃなくて、根本的なアプローチとしてこれはオートメーション関数をこねくりまわすのではなくて ADSR 専用のノードを作ってしまうべきだろうという考えに至ったという事です。

つまりこういう事です。

なぜこういうノードが無いのか、と。

元々の思想からすればノードの出力は音信号で制御系はオートメーションという区分けとか、色々と本来の思惑から外れるかも知れませんが。ただ、こうする事でリトリガーの問題だけではなくて制御系信号を多数のノードに分配する際にノード間 connect() が使えるとか、色々とすっきりする事が多いと思われます(ノードの出力を使うと無条件に a-rate 処理になってしまうというのは負荷的には不利な点にはなりますかね)。

まあ、作ってみれば良いんですけどね。今はノードの中身を作れる AudioWorklet があるし。
これなら、ノード内で常に現在のエンベロープ値を把握しているので時刻をトリガーにしてディケイカーブを発動するのではなく、アタックカーブがピーク値に達した事をトリガーにしてノード内部でディケイを発動できるというわけです。

という事で、作ってみたものがこちらになります。

GitHub - audioworklet-adsrnode

せっかくなので attack / decay / sustain / release に加えて、アタックのカーブの曲がり具合を調整する attackcurve というパラメータも追加してあります。

ライブデモもありますのでチェックしてみてください

Posted by g200kg : 8:05 PM : PermaLink

2020/06/29 (2020年06月のアーカイブ)

Web Audio API での ADSR カーブ

Web Audio API でシンセを作る場合、元々 API の思想としてはエンベロープ曲線、いわゆる ADSR のカーブを生成するには各種のオートメーション関数を使う事が想定されています。つまり、GainNode の gain パラメータに対して

setValueAtTime()
linearRampToValueAtTime()
exponentialRampToValueAtTime()
setTargetAtTime()

等の関数でパラメータを時間と共に変化させるという機能を使用します。しかし実際にそれなりに実用的なシンセを作ろうとするとこれではうまく行かない、あるいはとても面倒くさい、という事が起こります。それが「リトリガーへの対応」です。

ADSR は鍵盤を押した時、離した時のタイミングを基に下の図のような音量変化の曲線を作ります。各部の曲線は基本的に setTargetAtTime() による目標値に漸近する指数曲線 :

\(v(t) = V_1 + (V_0 - V_1)\, e^{-\left(\frac{t - T_0}{\tau}\right)}\)

で作れます。

問題は 2 回連続で鍵盤を素早く弾いた時です。1 回目の打鍵の曲線がまだ収束していない時に 2 回目の曲線が始まり、単に同じ曲線を繋げると不連続点ができてしまいます。この不連続点はノイズとして聞こえますので、対処が必要です。

でどうするかですけど、色々な考え方はあると思いますが、典型的なアナログシンセではどうなるかと言うと、次の図です。現在の値から ADSR 曲線が始まり、その分、2 つ目のピークになる点も少しだけ前倒しされます。ちなみに良くない例でありがちなのはアタック時のピークの時刻、つまり decay の始まる時刻を維持するために上りのカーブの傾きを変えてしまう事ですね。アタックのニュアンスが変わってしまいます。

ところがこれをオートメーション関数で実現しようとすると厄介な事になります。各部の曲線を指定するのはターゲットとなる値と発動する時刻がパラメータとして必要なので、2 回目の打鍵におけるアタック、ディケイ曲線を指定するにはリリース曲線の途中にある値を取得し、そこから 2 個目のピークになる時刻を計算する必要が出てきます。

何故こんな面倒な事になるかというと、Web Audio API のオートメーション機能はすべて時刻ベースのイベントで発動するのに対し、アナログシンセの ADSR では attack の次に decay が発動するタイミングというのは時刻で決まっているわけではなくてサンプル毎に現在の値を計算してゆく中で決まったピーク値になったら発動するものだからです。

という事で、これを根本的に解決するにはこのオートメーション関数のアプローチではちょっと筋が悪いのではないかと思うわけです。。。つまりどうするのが良いか。。。は次回に続く...

Web Audio API での ADSR カーブ (その2)

Posted by g200kg : 7:14 AM : PermaLink

2020/06/27 (2020年06月のアーカイブ)

Microsoft Edge 新バージョン到来

かねてより案内があった Microsoft Edge が Chromium ベースになるという話、ついに本日 Windows Update でうちにも自動配信されました。

edge://version でバージョン等確認できます。
ユーザーエージェントには Edg/81.0.416.81 というのが付いています。

設定画面なんかはかなりいじってるようではありますが、デベロッパーツールなんかを開くと大体 Chrome な感じですね。Web Audio の最新機能である AudioWorklet なんかもちゃんと動作しています。まあ Web Audio 関係では最近はどちらかと言うと Apple Safari がアップデートしてくれなくて足並みを乱している感がありますが。

さて、これである意味貴重な HTML レンダリングエンジンである edgeHTML が姿を消し、もう Webkit-Blink と Firefox の Gecko しか残ってない事になるのだが、この先どうなりますかね...。

Posted by g200kg : 9:09 PM : PermaLink

2020/06/24 (2020年06月のアーカイブ)

Web Audio API CR 2020年6月11日版日本語訳

W3C の Web Audio API, Candidate Recommendation が6月11日に更新されてから約2週間、地道に翻訳してなんとか日本語訳をアップデートしました。新しい機能が入ったとかいう事はありませんが各セクションの説明に追加、修正などが行われています。

ものが API の仕様書ですので、読み物として読むにはつらいのと、オーディオ DSP 系とモダンな Javascript の両方の知識が必要なのが厳しい所ですが、これは Web Audio API を使う側向けの説明だけではなく、Web Audio API の内部を実装するために必要な情報が詰まっていますので、単にオーディオ DSP に興味ある人にとっても有意義な内容になっています。

かなりの容量ですが、オーディオ DSP を広く網羅して突っ込んだ内容の文書というのはなかなか貴重なのではないかと思います。

活用していたただければ。
また間違いなどみつけましたら、GitHub issue へ。
Web Audio API, W3C Candidate Recommendation, 11 June 2020 (日本語訳)

Posted by g200kg : 3:02 PM : PermaLink

2020/06/12 (2020年06月のアーカイブ)

Web Audio API が更新

昨日6月11日に W3C で公開されている WebAudio API が「W3C Candidate Recommendation, 11 June 2020」として更新されました。

Web Audio API

前回の更新で Working Draft (草案) から初めて Candidate Recommendation (勧告候補) になったのが2018年9月なので1年9カ月ぶりですね。今回も Candidate Recommendation 版なのは同じで、基本的に API の説明の細かな間違いや不明瞭な点が修正されているだけですので、新しい機能の追加などはありません。

前回の CR 版との差異については Change Log にまとまっています。

また、Call for Exclusions の申し立て期間が2020年8月10日までとアナウンスされています。これはつまり W3C の定める規格はパテントポリシーとして特許料の支払いが必要なものは基本的には含めないのだけど、もし「この部分はうちの特許に抵触しているので勝手に使わないでくれ」と申し立てをするのなら8月10日まで、という事ですね。

今後の予定がどう進むのかちゃんと把握していませんけど、問題なければ現在の CR から PR (Proposed Recommendation) に進み、4週間以上の諮問委員会によるレビューの後、Recommendation、いわゆる W3C 勧告となるという風に進むようです。

Posted by g200kg : 5:32 PM : PermaLink

2020/04/01 (2020年04月のアーカイブ)

3Dプリンターで作るマスク

コロナ騒ぎでマスク不足の中、イグアス社が3Dプリンター製マスクのSTLデータを公開したと聞いて、家のプリンターで出力してみました。フィルター部は布なり紙なりを自分で張り付けてくださいという事です。

公開ページ :
https://www.iguazu-xyz.jp/knowledge/trend_02

男性用 / 女性用 / 子供用があり、それぞれ厚手と薄手があります。厚手は2mm 薄手は1.2mm くらいの厚さになっています。割れてしまったりしやすそうではあるけど、可能なら薄手の方が良さそうです。家庭用のFDMプリンタではまあまあ難易度は高目ですが頑張ればいけます。

薄手をABSで出力するとそれなりに弾力があるので顔にフィットする感じになりますが、顔に接する側にサポートがびっちり付くので丁寧に取らないとマスクを付けた時に顔にパリが刺さって痛いです。

なお横幅が150mm程ありますので、造形サイズはそれ以上のプリンターが必須です。

この、マスクが足りないなら3Dプリンターで作ろうぜ、という動きは海外のコミュニティー等でも行われているのですが、いかつい感じのが多くてちょっと不審者ぽくなりそうです。イグアス社のはおとなしめで普通に使えるイメージですかね。日本の会社なのでサイズも平均的な日本人に合ってそうです。

対コロナウイルスツールコレクション:
https://cults3d.com/en/collections/useful-3d-printed-coronavirus-covid19-tool

Posted by g200kg : 9:32 PM : PermaLink

2020/03/23 (2020年03月のアーカイブ)

favicon は丸くしようか

去年の9月頃から Chrome でウェブページを表示する際のタブ内のロード中に回転するアニメーションで favicon が表示されるようになりました。

気にするかどうかはデザインにもよると思いますが、角型を目いっぱい使っていると角が欠けてしまっていまいちな感じになりますね。丸形に切り取っても不自然にならないようにした方が良さそうです。更に、ロード中の favicon は微妙に縮小されているようなので確認してみた所、通常 16x16 で表示されている所が 10x10 になっています。

10x10 で表示して丸形に切り取ってもちゃんと視認できる、というのが今後は必要なんですかね。

Posted by g200kg : 12:03 PM : PermaLink

2020/03/11 (2020年03月のアーカイブ)

スナップ式ユーロラックレール

Twitter の方には昨日動画をあげてしまったのですが、スナップ式のユーロラックレール (43HP) を DMM.make のクリエイターズマーケットに登録・公開しました。これは見ていただけれはわかると思いますが、ユーロラックモジュラーシンセのケースを作るためのもので、モジュールをハメ込むだけで固定する事ができるようになっています。

サイドパネルを留める穴はタカチの FFR レールと同じ位置になっていて、先日別途公開したサイドパネル(eurorack_side_2)を使って組み立てる事ができます。

このレールには上下があります。並んだ穴が開いているのが上側のレール、穴がないのが下側のレールです。窓や引き戸等をハメ込むような感じで上側に押さえつけながら入れると入るようになっています。

DMM.make クリエイターズマーケット : Eurorack_rail_snap_43HP

組み立てた状態はこんな感じになります。

また、しっかりとモジュールを固定したい場合は上面の穴に M3 x 6 のネジ (モジュールに良く付属しているサイズ) を入れて締めると完全に固定されます。

組立には M4 x 10～16 程度のタッピングネジが必要です。Amazon等で「M4 タッピング」等で探してください(タカチのレール付属のネジでも良いです)。
対応できるモジュールのパネルの厚さは 2.0mm まで (TipTop Audio の uZEUS の厚さ) です。それ以上厚いパネルのモジュールは止められません。
素材はナイロン樹脂、白のみです。

ネジをいちいち外してのモジュールの入れ替えの面倒臭さはユーロラックモジュラーを触った人じゃないとわからないかも知れませんが、とにかく面倒です。構造的にかなりの高精度な3Dプリンタでの出力が必要なので、小ぶりの割にはどうしても結構値が張る感じになってしまいますが、色々と組み合わせの実験用としていかがでしょうか。

DMM.make のクリエイターズマーケットでどなたでも注文が可能です。
(注文があってから出力するので届くまで1週間近くかかる事もあります)

Posted by g200kg : 6:37 PM : PermaLink

2020/02/28 (2020年02月のアーカイブ)

DMMでユーロラックケースのサイドパネルを公開

ユーロラックのケースを自作する際に使うレールとして、取り合えず入手しやすいという事でタカチのサブラック用フロントレール FFR-43N ( +バーナット BN43－M3 )を使う方は多いのではないでしょうか。レール自体の幅がかなりあるのでサイドパネルだけなんとかすればまあまあそれっぽい感じにできるというのもあるし、自作系の人にはお馴染みの秋葉原のマルツ等で手に入るという事もあります。

問題としては一般的にモジュールに付いてくる M3 x 6mm ではモジュールを固定できず、M3 x 10mm ネジを別途準備しないといけないというのはあるんですけどね。

マルツ FFR-43Nのページ

で、後はサイドパネルをどうするか。木材やアルミ板等で工作するというのが一般的かと思いますが、これを3Dプリンタで作れるように、DMM.make の 3D プリント・クリエイターズマーケットという所に FFR レールに適合するサイドパネルを登録して公開しました。どなたでも DMM.make にサイドパネルを注文できます。

DMMクリエイターズマーケット eurorack_side_2

サイドパネルを固定するネジはレールに付属のものが使えます。
組み立てるとこんな感じになります。

※ なお、この写真のレールは FFR-22N で 42HP のものですが、現在は生産終了となっており、現行の商品は 84HP の FFR-43N のみとなっています。

なお、DMMの3Dプリントは注文を受けてから印刷を開始して発送されますので、今の実感としては4～5日くらいで届くというイメージですが週末をはさんだりするとそれだけ長くかかる感じです。

とにかく手間を省きたいという場合はこれでいかがでしょうか。

Posted by g200kg : 9:22 PM : PermaLink

2020/02/16 (2020年02月のアーカイブ)

3Dプリンタ QIDI X-Smart の分解掃除

相変わらず3Dプリンタで遊んでますが、PETGフィラメントの様子もわかったし次はABSフィラメントにするか、と始めた所でトラブルです。ノズルが完全に詰まってしまいました。

原因は一目瞭然で、供給側のフィラメントが絡まって送れなくなり焼け焦げてしまったようです。そういえば今回のフィラメントは安いのを買ったのだけど前のに比べると巻き方が適当な感じなのは関係してるのでしょうか...。

今までにもちょっと詰まったりした事はあったのですが、フィラメントを無理やり押し込んだりする事で解消できていました。今回の詰まりはどうやっても動かないかなり頑固な詰まりのようです。

しょうがないので分解する事にしました。

ノズルを外すにはヒートブロックに差し込んだネジとレンチを使います。このネジとレンチは付属品に入っています。

ノズル先端の詰まりならここまで何とかできるのですが、今回はもっと奥の方まで詰まっているようなので更に分解します。

その奥のアルミブロックのネジを外すとステッピングモーター、ヒートシンク、アルミブロック周りがバラバラになります。

この辺まで来ると、これ元に戻せるのか? と不安になるレベルでバラバラになりますが、詰まった場所にアクセスするにはバラすしかないですね。

ノズル先端部の詰まりはピンセットでつついていると取れました。先端の黒いのは今まで使っていた黒のPETGがこびりついていたのだろうか。これも悪さしてそうで、なんかPETGフィラメントのイメージが爆下がりです(世間の評判は悪くないみたいなので個人の感想ですが)。

で、こちらがアルミブロック部分で詰まってた奴。加熱するかアセトンで溶かすかというあたりが選択肢のようですが、今回はヒートガンであぶりつつピンセットでつまみ出しました。

逆の手順で組み立てて詰まりが解消した事を確認。アルミブロックを外す辺りで完全にバラバラになるので、構造をちゃんと覚えておかないと困った事になります。

という事でなんとかなりました。

しかしこういうトラブルはまあまあの頻度で起こっているらしい、にしては難易度は高めですね。

界隈では「どこのご家庭にもある3Dプリンタ」みたいに言われたりしますが、それなりの覚悟は必要ですかね。まあQIDIはサポートが懇切丁寧という評判なので頑張っていると思います。

Posted by g200kg : 4:30 AM : PermaLink

2020/02/04 (2020年02月のアーカイブ)

PETGフィラメントを使いたい

3Dプリンタ初心者なのでまだ色々と手探りですが、綺麗に出力するのはなかなか難しいです。

現在の状況をまとめると...

まず3Dプリンタで使うフィラメントの素材はPLAとABSが代表的なのですが、それぞれ特徴があります。PLAは最も3Dプリンタで出力しやすく、最初プリンタに付属していたフィラメントもこれ。ただし熱に弱く、硬くてもろい。ABSは一般的にも良く使われるプラスチックで、ある程度の靭性があり、PLAより熱にも衝撃にも強い。ただし反りが発生しやすく、糸引き現象も起こりやすい。あと印刷中くさい。

という所でPLAとABSの中間的なフィラメントが登場、これがPETG。くさくない。多少靭性があり、衝撃や熱に対する強度はPLAとABSの中間。糸引きはあるものの反りはほとんど起こらない。これからはPETGだぜ!

という記事をどこかで見て、PETGフィラメントを買ってみたわけです。ペットボトルに使われているPETを改良したものらしいです。

で、やってみたのですが時々表面にフィラメントのゴミの塊みたいなのがへばりつきます。印刷の度にノズルの出口あたりに樹脂のクズがべっとりと付くので、この辺が問題なのだろうなとは思うけど、どうやら、デフォルトのパラメータで気軽に使うというわけには行かなさそうです。

しょうがないので最適な温度を探る事に。

PETGフィラメントの仕様によれば印刷温度は220℃～250℃となっているので10℃ずつ変えて出力。ちなみにこのモデルは3DBenchyと言う3Dプリンタのベンチマーク用に良く使われる船のデータです。残念ながらフィラメントが黒色なので凄く見づらい。

http://www.3dbenchy.com/

220℃あたりだとどうやら船尾の平面とか天井部分とか、何でもない平面の所にゴミが発生しやすい。思うにノズルから出た直後の粘性が高すぎてノズル周りに残り、周りを巻き込んでしまうのではないかという気がする。

温度が高い方がゴミの発生率が低いようだ。

一方で250℃あたりになると船の舳先周辺に妙な糸引きが発生する。これは多分問題なく掃除できそうではあるけど。

船首の裏側あたりがあんまり綺麗じゃない。温度高目の方がましにはなる。

という事でプリンタのPETGの設定は220℃がデフォルトだったのだけど、今後240℃あたりで使ってみようかと思う。なお設定は温度以外にも速度や引き戻し量など色々あるので本当に最適な条件を探るのはかなり大変。

家庭用3Dプリンタが出てからかなり経った今なら、もうこんな試行錯誤しなくてもさくっと良い感じに使えるかと思ったのだけど、そういうものでもないらしい。

Posted by g200kg : 8:05 AM : PermaLink

2020/01/23 (2020年01月のアーカイブ)

3Dプリンタ導入しました

家庭用の3Dプリンタがお手頃価格になってからもう結構経っていますが、数年前まではまだ精度的に不満があるとか、印刷の条件を地道に詰めないと失敗するとかいう話も聞いていたので、まあ必要な時にDMMプリントとかに頼めばいいや、というスタンスだったんですけどね。

もう流石にそろそろイケるんじゃないかなあ、という事で導入しました。QIDIのX-Smartという機種です。ワークサイズは170mm x 150mm x 150mm、フレームむき出しじゃなくて箱型の筐体な所がなんとなく安心感があります。

ユーロラックモジュラーのケースを一気に出力してみるテスト。

出力に丸々半日はかかっていますが 26HP のケースができました。レールもバーナットも無しで3Dプリンタだけでユーロラックケースを作れるというのは素晴らしい。ただしネジはモジュールが落ちないように優しく止めるだけ。それから発熱するモジュールには注意。ケースごと溶けそう。

それでも良ければSTLファイルはここ↓にあります。ネジ穴はΦ3の八角形で出力していますが、プリンタによっては微調整が必要かも。
20200123eurorackcase.stl

プリンタのワークサイズは140mm x 140mm が必要です。ユーロラックの3Uのパネルは高さ128mmくらいあるのですが、家庭用3Dプリンタのエントリーモデルはワークサイズが100mm x 100mm という機種が多くてユーロラック絡みでは活躍しづらいのが残念なんですよね。

ちなみにDMMプリントだと価格が外形体積依存なのでこういう中空の箱型だととても高くなります。

その前に基本的な事を幾つかテスト。フィラメントはPLAです。出力する部品に直接ネジを使えるかどうか。

M3くらいのネジで組み立てたりしたいのだけど、ネジ山の微細な構造を作れるわけではないので、小さめの穴を開けてネジで固定できるかどうかのテスト。

穴は3Dプリントすると若干小さくなります。フィラメントやプリンタの機種によっても違うので現物合わせで調整が必要ですが、バカ穴にするには Φ3.5 くらい、ネジ止めするにはΦ2.7くらいの穴を開けておいてタッピングビスを使うくらいが安定、Φ2.8～Φ3.0くらいの穴を開けておけば普通のネジでも一応止まります。力を入れるとすぐに削れてしまうので、取り合えず止められるという程度ですが、試験的にちょっと組み立ててみるというような使い方ならいけそう。

蝶番構造は作れるか。繋がった状態の蝶番構造をそのまま出力できるのは3Dプリンタの良い所ではあるのですが、2つの部品間のギャップの調整がかなり微妙です。

部品間のギャップが 0.2mm だと完全にくっ付いてしまって動かせない蝶番ができました。ギャップ0.3mmならちゃんと動く蝶番になり、ギャップが0.5mmだとかなりユルユルになります。調整が本当に微妙。

という事で、作りかけの謎楽器の筐体を作ったりしています。ワークサイズが足りないので、複数に分割してはめ合わせで組めるようしていますが、まだまだ試行錯誤が必要。

Posted by g200kg : 8:00 AM : PermaLink

2019/12/25 (2019年12月のアーカイブ)

新しいユーロラックモジュール

久しぶりに新しいユーロラックモジュールを作った。

珍しく黒パネルにしてみました。これは小規模システム向けの 4HP、USB 給電のユーロラック電源モジュールです。普通の PC の USB ポートからでも動かせますが、ここから ±12V を作るのでこの場合の限界はせいぜい 100mA 程度ですかね。

RasPi用とかの容量に余裕がある USB 電源なら +12V:500mA、-12V:120mAくらい。
なんでわざわざ USB からの供給かと言うと、ここにモバイルバッテリーを繋ぐと結構な稼働時間のスタンドアローンなユーロラックシステムができそうかなと思ったので。

とは言うものの、MicroUSB コネクタの接続ってどうも頼りなくて困る。ケーブルの取り回しが問題だな。

Posted by g200kg : 9:37 PM : PermaLink

2019/12/25 (2019年12月のアーカイブ)

「サイトまたはアプリでのデータ侵害により、パスワード情報が漏洩しました。」

とあるMovableTypeのダッシュボードを開こうとしていきなりこんな警告が出たからびっくりしたじゃないか。どうやら12月10日頃にChromeに新しく実装された警告機能らしいです。

まずはこの画面自体が怪しいものではないかどうかを疑ってしまうのですが、これはどうやらこれまでにあった漏洩事故のデータとChromeブラウザが記憶しているパスワードの照合を行うもののようです。流出事故の話があってもどうでも良さそうなサイトで使っていたパスワードについては放置したりしていたので怒られたという事ですね。

今年の初めくらいにブラウザが保持しているパスワードとこれまでに漏洩したパスワードを照合するパスワードチェック機能 (Password Checkup) のChrome拡張が既に発表されていましたが、どうやらこれが普通にブラウズする際にも有効になったという事なのかな。

ここがGoogle本家の紹介です。
https://blog.google/products/chrome/better-password-protections/

この画面から「パスワードを確認」のボタンを押すと下のような画面になり、事故があったパスワードがそのまま残っている、複数のサイトで使いまわしされている、パスワードの強度が弱い、というそれぞれの件数が表示されます。

私としてはあまりブラウザにパスワードは覚えさせていないつもりだったのだけど、結構残ってますね。
パスワード管理については、今のところ基本的に KeePass を使ってるのだけど、Bitwardenとかいう新興勢力が出てきているようです。
一回整理するか。

Posted by g200kg : 8:34 PM : PermaLink

2019/12/07 (2019年12月のアーカイブ)

三端子レギュレータの裏技

ちょっとした電子工作でも電源周りで良くお世話になる三端子レギュレータというICが昔からあります。入力された電圧から安定した指定の電圧への変換を最小限の三本足だけでやってくれる便利なものですが、電圧差が大きいと発熱がバカにならずヒートシンクで悩んだりしますね。

という事で最近ではスイッチング方式のレギュレータを三端子レギュレータと同様のパッケージに全て封入したモジュールというのも割と目に付きます。電源の質とかは吟味が必要ですが、同じ三本足で差し替えるだけで熱の問題が片付いたりします。技術の進歩は凄いね。

で、このスイッチング方式のレギュレータには実は裏技的な使い方があるんですが、それがこれ↓　三端子レギュレータで負電圧を作り出すという方法です。

絶縁モジュールならともかく、非絶縁のレギュレータでこんな事して良いの? という気もしますが、出力をいきなりGNDに落として本来のGND端子から負の電圧を取り出すというやり方です。勿論通常の(リニアの)レギュレータだとショート状態になってしまいますが、スイッチング方式のレギュレータだと出力側にインダクタンスがあるのでこれでも成立します。モジュールの中身まで書くとトポロジー的には下の図になります。

このやり方についてはTIのアプリケーションレポートが詳しいです。
http://www.tij.co.jp/jp/lit/an/jaja235/jaja235.pdf

上の回路図はCUIというメーカーのスイッチングレギュレータ(V78XX)のもので、秋月でも扱っていて、「負電源用としても使えます」とわざわざ説明がついています。
http://akizukidenshi.com/catalog/g/gM-06350/

さて、せっかく便利な裏技的な話をした所ですが、実はところがこのV78XX、秋月が負電源に使える例として参考にあげているデータシートは少し古くて最新のデータシートを漁ると負電源として使う例がばっさり削られていて、「負電源に使うのは推奨しない」となっています。

https://www.cui.com/product/resource/v78xx-1000.pdf

あー残念。駄目みたいですね。

一度はデータシートに載せていたものを改訂してまで非推奨にするというのは何か問題があったのでしょうか。
ここから先は想像ですけど、問題があるとすると入力耐圧かな、と。スイッチの制御系の回路はどうやって動作するかというと、+Vin と -Voutに挟まれて動くわけで、通常の動作状態よりも高い電圧がかかります。15V入力で12V出力なら27Vです。V78XXの例だと、モデルによりますが標準24V入力で15V出力のものがあり、これだと39V掛かる事になるのに入力の耐圧の定格は32Vmaxなんですよね。

まあ、このあたりに気を付ければ大丈夫ではないかと思いますが、メーカーとしては非推奨という事なので自己責任で。

Posted by g200kg : 7:13 PM : PermaLink