2022/12/30 (2022年12月 のアーカイブ)
WebWorkerでゴリゴリの重い処理をさせて横から制御したい時の手段
これは Javascript のかなり細かい部分の話なので似たようなケースで困った事がある人以外にとってはどうでも良い話だと思いますが......。
JavaScript は元々シングルスレッド構造なのであまり重い処理をさせるには向いていないのだ、という事は昔から言われていました。 重い処理をしようとした時にまず影響を受けやすいのは UI 周りの動作です。
UI をちゃんと動かしつつ重い処理をさせるためには、処理を小分けにしてタイマーから駆動する等の手法がとられます。 またこの時、コールバックで小分けにした処理を繋げるとソースが見づらくなるので Promise や async/await を使う、という手段が定石となっていったのですが、そもそも、ひとまとまりの重い処理をやらせたいならやっぱり別スレッドで走らせたい、という事で WebWorker というものが作られました。
これによって Javascript は OS レベルで保証されたマルチスレッドな環境を手に入れた訳です。ただし、この時のメインスレッドとワーカースレッドは空間が分離されており、スレッド間の通信は postMessage() によるメッセージのやり取りで行う必要があります。
まあこれで大体のやりたい事はできるようになったのですが、次のコードを見てください。メインスレッドからの指示で WebWorkerで 10 秒かかる処理を開始/中止するつもりのコードです。
"START" ボタンを押すとワーカー側で 10 秒数える無限ループ的な処理を開始し、"ABORT" ボタンで中止フラグを立てているつもりですが、残念ながらこれはうまく動きません。
main.js
let worker = new Worker('worker-1.js');
document.getElementById('start').addEventListener('click', ()=>{
worker.postMessage('start');
console.log('post "start"');
});
document.getElementById('abort').addEventListener('click', ()=>{
worker.postMessage('abort');
console.log('post "abort"');
});
worker-1.js
let abort = 0;
let current = 0;
function start() {
abort = current = 0;
console.log('Heavy task start');
const startTime = new Date();
while(current < 10) {
const elapsed = Math.floor((new Date() - startTime)/1000);
if(elapsed != current) {
console.log(current = elapsed);
}
if(abort) {
console.log('Heavy task abort');
break;
}
}
console.log('Heavy task end');
}
onmessage = (ev)=>{
switch(ev.data) {
case 'start':
console.log('recv "start"')
start();
break;
case 'abort':
console.log('recv "abort"');
abort = 1;
break;
}
}
これを走らせると次のようになります。
"START" を押すと数を数え始めるのは良いのですがカウントが 5 になった時に "ABORT" を押しても止まらず、10 まで数え終わってから "abort" を受け取っています。メイン側は "abort" メッセージを送信していますが、ワーカー側に届いていません。ワーカーはメッセージを受け取るための onmessage の処理をマイクロタスクとしてキューに入れますがこのマイクロタスクは現在実行中のタスクが終わらないと走り始めないためです。結局ワーカー側は重い処理の途中で送られたメッセージを受け取る暇もなく動き続けるという事になります。
単にワーカーを止めたいだけならメイン側から直接 worker.terminate() を呼び出す事もできますが、一旦停止して後で続きを再開させたい、とか、重い処理の途中で追加の情報を送りたい、とかいう場合には対応できません。
元々シングルスレッドしか想定していなかった所にマルチスレッドを持ち込んだからこうなっちゃったのかなとは思いますが、こういう場合どうするか、と言うと、こういう場合に使える手段はちゃんとあります。それが SharedArrayBuffer、略して SAB 等とも呼ばれるもので、これはスレッド間の共有メモリとなります。ワーカー側でメッセージを受け取る暇がなくても処理を中断するためのフラグを立てるだけならメイン側の処理で行う事が可能です。
これを使うと下のコードのようになります。ここでは共有メモリとして 1 バイトの中止フラグだけを作っています。なお、もっと大きなサイズで複雑なデータをやり取りする事も可能ですが、高度な操作をするのならスレッド間の競合も気にする必要がでてきますので、Atomic API で競合を避ける必要があります。
main.js
let worker = new Worker('worker-2.js');
let sab = new SharedArrayBuffer(1);
let abort = new Uint8Array(sab);
document.getElementById('start').addEventListener('click', ()=>{
worker.postMessage(['start', sab]);
console.log('post "start"');
});
document.getElementById('abort').addEventListener('click', ()=>{
abort[0] = 1;
console.log('set "abort" flag');
});
worker-2.js
let abort, current;
function start() {
current = 0;
abort[0] = 0;
console.log('Heavy task start');
const startTime = new Date();
while(current < 10) {
const elapsed = Math.floor((new Date() - startTime)/1000);
if(elapsed != current) {
console.log(current = elapsed);
}
if(abort[0]) {
console.log('Heavy task abort');
break;
}
}
console.log('Heavy task end');
}
onmessage = (ev)=>{
switch(ev.data[0]) {
case 'start':
const sab = ev.data[1];
abort = new Uint8Array(sab);
console.log('recv "start"')
start();
break;
}
}
これを走らせたのが下の図で、重い処理の途中でも "ABORT" ボタンを押したタイミングで止まってますね。
めでたしめでたし、ではあるのですが、この SAB にまつわる問題はこれまでに結構な紆余曲折があり、CPU レベルでのセキュリティ上の懸念があるという指摘により対応するブラウザのリリースが延期されたりしていたのです。ちなみに WebWorker がサポートされ始めたのが 2010 年頃、その後 SAB が一度提案されたものの問題の指摘により一旦無効化され、最終的に対応方法が決まったのが 2021 年頃なので結構長い間この、マルチスレッドではあるけどちょっと使いづらい問題は引きずっていた気がします。
SAB を有効化するために必要な対応が「クロスオリジン分離 (cross-origin-isolation) 」で、ブラウザでこの機能を使うにはサーバ側で COOP および COEP と呼ばれる特殊なヘッダーを設定する必要があります。このヘッダーがないとブラウザはこの SAB の API 自体をサポートしていないものとして扱います。
Chrome では 2021 年の Chrome 91 でクロスオリジン分離を必須とする対応になる時、使っているライブラリ内で知らず知らずの内に暫定の対応経由で SAB を使っていたサイトに対して google からもうすぐ動かなくなるよと警告が送られてちょっとした騒ぎになったりしていました。
まあ自分が管理しているサーバならば必要なヘッダーを追加してやれば良いのですが、ヘッダーを勝手にいじれない例えば GitHub Pages で使いたい場合はどうすれば?? とここで詰んだかと思ったのですが、やる人はいるもので、WebWorker の親戚のサービスワーカー(ServiceWorker) という機能を使って SAB に必要なヘッダーを補完するライブラリ (coi-serviceworker) が作られています。
https://github.com/gzuidhof/coi-serviceworker
npm が使えるなら
npm i --save coi-serviceworker
でインストールできます。これを使って
<script src="node_modules/coi-serviceworker/coi-serviceworker.js"></script>
という風に読み込んでやればサーバ側のヘッダー設定をいじれなくても SAB を使う事が可能になります。
なお更に追記ですが、このサービスワーカーはプッシュ通知等で使われる事が多いのですが、ユーザーが知らない所でバックグラウンドで動作するとして嫌う人もいます。ブラウザの設定でサービスワーカーを拒否するような措置が取られている場合には coi-serviceworker を使う事はできません。できれば素直に自分でヘッダー設定が可能なサーバを使いましょう。
Posted by g200kg : 11:24 AM : PermaLink
2022/12/25 (2022年12月 のアーカイブ)
GAME言語インタプリタを作ってみた
1970 年代の終わり頃、8bit CPU を使ったパーソナルコンピューターが各社から出そろって何とか趣味でコンピューターが使えるようになった当時、使用可能な言語処理系と言えば BASIC かマシン語をハンドアセンブルするしかなかった時代にそれに飽き足らなくなったマニア達が独自の言語処理系を作るというのが流行った事がありました。
中でも私が気に入っていたのは GAME 言語という奴。その源流は Altair の VTL (Very Tiny Language) と呼ばれるものらしいです。マイクロ BASIC 風ですが予約語は全部記号の組み合わせで表すという見るからに怪しいコードがとても良い雰囲気でした。しかもインタプリタだけでなくコンパイラも存在し、さらにそのコンパイラが GAME 言語自体で記述されているという構造がとてもそそります。詳細な言語仕様もかなりおぼろげだったんですが、最近 GitHub に当時の GAME コンパイラのコードが公開されているのを知りました。
https://github.com/snakajima/game-compiler
GAME 言語の文法については (http://www.mztn.org/game86/あたりを参照してください。
このコンパイラは80系CPUが前提のようですぐには試せないので、とりあえずオンラインでテストできるインタプリタを Javascript で書いてみました。ただし、速度がとんでもなく遅いです。これは値の評価途中でキー入力を待つケースがあり、値の評価自体をあまり考えずに async/await だらけで書いたためで、もうちょっと構造を考え直す必要はありそうです。
簡単なサンプルを幾つか付けてありますので選択して "Load" ボタンを押すとロードされます。
GitHub : https://github.com/g200kg/game-interpreter
デモ : https://g200kg.github.io/game-interpreter/gameinterpreter.html
Posted by g200kg : 8:53 PM : PermaLink
2022/09/05 (2022年09月 のアーカイブ)
メイカーフェア東京2022 (MFT2022) に出展しました
先週末、9月3~4日に、東京ビッグサイトにてメイカーフェア東京2022 ( MFT2022 ) が開催されました。
Web Music Developers JP 名義で出展してきましたので、ミュージックカテゴリの周辺だけですが、気になったものなどを少しご紹介します。
イベント名称 : Maker Faire Tokyo 2022 (MFT2022)
日時 : 2022年9月3日(土) 12:00 - 18:00 2022年9月4日(日) 10:00 - 17:00
会場 : 東京ビッグサイト (西4ホール)
主催 : 株式会社オライリー・ジャパン

山下さんのアームテルミン。最新版はコントローラーと音源が分離しているタイプ。MCUは328PからSTM32になった模様
久しぶりのオンサイトイベントですが、結構盛況だったと思います。
なお、展示した「SOROBAN v2.5」「ElectroGurdy」については
テクノエッジ : ギタリストワナビーの聖杯「表現力豊かなソロが弾ける電子ギター」をMaker Faire Tokyo 2022で手に入れた
AV Watch : 未来の電子楽器大集合!? ものづくり祭典「Maker Faire」に行ってみた
で記事にしていただきました。
Posted by g200kg : 6:00 PM : PermaLink
2022/06/12 (2022年06月 のアーカイブ)
電子ハーディーガーディー Electro Gurdy
一か月ほど前にレア楽器の「ハーディーガーディー」のキットを組み立てた話を書きました。
下にリンクを貼っているので見ればわかりますが、組み立てたのは基本的には模型のキットという位置づけのものです。
実際に楽器として使うのはかなり難しいのですが、構造的には非常に興味深いものです。
という事で、このハーディーガーディーを電子楽器として作ったら面白いのではないかなあと思って作ってみました。
使い勝手がどうなるかとりあえず作ってみない事には判断できないので、見切り発車気味にざっくり回路図を書いて
基板を起こします。
ハーディーガーディー最大の特徴と言えるハンドル部分はこんな感じ。
* MCUはSTM32、Nucleo ボードをそのまま使います
* 右手のハンドルはギア経由でモーターを回して発生した電圧をADCで読む
という作戦で行きます。
それで基板を作ってとりあえず音が出る状態までしたのが下の動画です。
どうもね。左手キー部分の扱いがちょっと難しいです。本来のハーディーガーディーの演奏ポジションだと指で下から上にキーを押し上げる形になって手のひらで本体を抑えるような形になるんですが、普通の鍵盤ぽく指でキーを押さえる形にしたのでポジションが定まらない感じはします。慣れの問題かも知れませんが。
まあとにかくこれで筐体を3Dプリンタで作って...
ついでにせっかく電子化したので、本来のハーディーガーディーではできない機能も付けてみます。
ハーディーガーディーはバグパイプと同じで持続するドローン音が出るのだけどをこれをハンドルの回転方向で切り替えられるようにしてみました。
これを使った演奏が下の動画です。
まだ色々未完成な所もあるのだけど、多分今年の Maker Faire Tokyo 2022 (9月3~4日) には持っていきますので、Maker Faire 2022 参加予定の人はよろしくお願いします。
Posted by g200kg : 3:47 PM : PermaLink
2022/05/14 (2022年05月 のアーカイブ)
0.96" OLED ディスプレイの仕様はどうなっているのか
数年前から0.96インチで 128 x 64 の小さなOLEDディスプレイモジュールがAmazonやらAliExpressやらで安く大量に売られています。秋月電子でも扱っていますね。
特にI2C接続のものは4線の接続だけで使えるので描画速度には難があるもののちょっとした表示用にとてもお手軽で良くて何度か使っているのですが、一方でちょっと困った問題があります。とにかく見た目はほぼ同じだけど少しずつ違うものが中国系の良くわからないブランドから大量に流通しているので現物合わせで使うしかないという状況です。ロットが変わる度に少しずつ変更が入ったりするので同じ品物が長期に渡って入手できるとは考えない方が良いです。
国内での入手先として比較的安定していると思われる秋月電子でも、モジュールの詳細な寸法図等については「ロットによって変わる(既に何度か変わっている)」という注意書きが付いています。
ピン配置の互換性
一番重要な点としてピン配列が [ GND VCC SCL SDA ]型のものと [ VCC GND SCL SDA ] 型のものが混在しています。これを間違えると確実に壊すので気を付けたい所ですが、困った事に勢力的には現在は半々くらいで流通しています(さらに例外的におかしな配列ものものも稀にあります)。
これまでの観測によれば新しいものほど[ GND VCC SCL SDA ]型が多いように感じられ、いずれは収束していくかも知れませんが、今は現物を確認するしか方法がありません。
コントローラーの違い
殆どのものはディスプレイコントローラーとして SSD1306 が使用されていますが、たまに SSD1315 など異なるコントローラーが搭載されている事があります。I2Cコマンドレベルでもまあまあ互換性があるようですし、ミドルウェアとしてよく使われるライブラリもメジャーなものならばサポートしていたりしますので結構動作しそうではありますが、機能を直叩きで隅々まで使うならば問題が起こる事があります。
製品によって寸法がバラバラ
バラックで動かす場合等はピン配置とかコントローラーの種類に気を付ければ類似製品ならどれでもそれなりに動くのですが、何かのガジェットに部品として組み込んで使いたい時は正確なサイズ等が欲しい所ですが、これがとにかく安定しません。
とにかく現在Amazon等で流通しているものの中でそれなりに良く見かけるものについて、基板のサイズ、ネジ穴の位置をわかるものだけざっと調べてみました。(この公開されているデータがそもそも正確かどうかも怪しいですが)
ブランド | ピン配置 | PCBサイズ | ネジ穴位置 | ネジ穴サイズ | URL |
---|---|---|---|---|---|
Aideepen | GND VCC SCL SDA | 27.5 x 27.8 | 23.5 x 23.8 | 4-φ2.0 | amazon |
VKLSVAN | GND VCC SCL SDA | 25.2 x 26.00 | 21.00 x 21.8 | 4-φ2.0 | amazon |
Resbee | GND VCC SCL SDA | 27.5 x 27.8 | 23.5 x 23.8 | 4-φ2.0 | amazon |
KeeYees | GND VCC SCL SDA | 25.4 x 26.1 | 21.8 x 22.6 | 4-φ2.0 (推測) | amazon |
Winstar | VCC GND SCL SDA | 26.7 x 19.26 | 20.7 x 23.2 | 4-φ2.5 | winstar |
EShine | VSS VDD SCL SDA | 27.3 x 27.8 | 23.3 x 23.8 | 4-φ2.54 | made-in-china |
LY | GND VCC SCL SDA | 27.2 x 27.2 | 21.74 x 19.26 | 4-φ2 | alibaba |
FriendlyElec | SDA SCL 5V GND | 27.3 x 27.3 | 20.7 x 23.2 | φ? (横長穴) | friendlyElec |
ZEKE | VCC GND SCL SDA | 27.3 x 27.3 | 20.7 x 23.2 | 4-φ? (横長穴) | rakuten |
IZOKEE | GND VCC SCL SDA | 25.4 x 26.1 | 20.7 x 21.5 | 4-φ? | amazon.ca |
EasyWordMall | VCC GND SCL SDA | 27.3 x 27.3 | 20.7 x 23.2 | φ? (横長穴) | amazon |
という事でどれが来てもネジで固定できそうなフットプリントを作れないものだろうかと4ピンヘッダーの位置をリファレンスとして右下のネジ穴位置を確認してみたのが↓の図です。
どれが来てもOKとは行きませんが、多少融通の効くフットプリントが作れない事もなさそうですが、どうせまたすぐ変わるだろうし、もう少し大きな1.3インチクラスの流通も増えてきて苦労の割には報われ無い可能性はあります。
今のところの現実的な解は4ピンのヘッダー部分で接続した後はホットボンドで固めてしまう、とか言う強引なやり方かも知れません。
Posted by g200kg : 1:52 PM : PermaLink
2022/04/27 (2022年04月 のアーカイブ)
ハーディーガーディーのキットを作ってみた
「ハーディーガーディー」という楽器をご存じでしょうか。
変な楽器好きの人なら知っているとは思いますが、ざっくり言えばバイオリンのような弦楽器がちょっと変な方向に進化したような楽器で、弓で弦を弾く代わりに手回しハンドルで回転する円盤で弦を擦って持続音を出す事ができる楽器です。また、メロディを演奏する旋律弦に加えて持続音を出すドローン弦が張られていますので、音の雰囲気としてはバグパイプにも近い部分があります。
かなりレアな楽器なので本物にはなかなかお目にかかれないのですが、アマゾンとか楽天でハーディーガーディーの模型が売られているのを時々目にします。これは、単にハーディーガーディーをかたどった置物的なものだと思って完全にスルーしていたのですが、ちゃんと組み立てれば一応音が出る状態になると最近知って買ってみました。ミニチュアですけど、なかなか凝った装飾がされています。

では実際にテストします。ぎりぎり音が出ているという感じですが、弦がただのテグスっぽいのでこの辺をちゃんとすれば音色としてはもっと良くなりそうな気はします。
一応音は出ますが、本格的な楽器として使う感じのものではありません。しかしこれだけ可動部分のある構造物を木製パーツのハメ込みだけで接着剤も使わず作れるというのはなかなか凄い事だと思います。構造を知るという意味ではとても興味深いものでした。
ではここでお気に入りのドイツのハーディーガーディー奏者、Patty Gurdy、ソロライブ版。 ハーディーガーディーの妙にメカメカしい感じが凄く良い。
ドイツの中世風コンセプト(メディエバルメタルと言うらしい)のバンド、ダルタニアンとのコラボ。良い。
Posted by g200kg : 12:35 PM : PermaLink
2022/04/21 (2022年04月 のアーカイブ)
第一回Pikoketが開催されました
先週の話になってしまいますが、4月16日(土)に電子工作者&シンセビルダー同人展示即売会「ピコケット」Pikoketが開催されました。場所は北の丸公園の科学技術館です。
第一回の開催という事でどんな感じになるのかよく判らずに参加したのですが、シンセ関係6割電子工作関係4割くらいのイメージですね。コロナ禍以来のオンサイトイベントという事もありちょっと様子を探りつつという所もありましたが、人が密集するというほどでもなく適度な混み具合だったと思います。
一部ですけど、展示物の様子など。

サーボモーターでノブを動かす部分の拡大。そう言えば回転式のポットをモータードライブするようなものって無いなあと思ってちょっと面白い。
まだまだリアルイベントを開催するには厳しい環境ですが、そろそろとこういう催しも復活しつつあるようです。まあ今後の状況次第ではありますが。
Posted by g200kg : 1:51 AM : PermaLink
2022/03/19 (2022年03月 のアーカイブ)
電子工作&シンセビルダー同人展示即売会「ピコケット」
4月16日(土)に電子楽器系の同人展示即売会「ピコケット」に参加します。
場所はお馴染みの科学技術館です。
まだ第一回目の開催という事ですのでどんな感じになるのかわかりませんが、久しぶりのオンサイトイベントです。
とは言えコロナの状況も油断はできないのでどうしましょうかね。難しい所です。
日時 2022年4月16日(土) 11~15時
場所 東京都千代田区北の丸公園2-1 科学技術館 第3会議室
主催 電子工作社 PikoPiko Factory
一般入場にはパンフレット(予価500円)の購入が必須です。
Posted by g200kg : 11:44 PM : PermaLink
2022/03/13 (2022年03月 のアーカイブ)
KiCad 6 の「プラグインとコンテンツマネージャー(PCM)」の使い方と対応プラグインの作り方
愛用の基板Cad KiCadは現在最新のリリースは既に6.0.2になっていますが、6.0 RC版はちょっと触ったものの実際は今まで5.xを使っていてようやく6.xに乗り換えました。
6.xへのメジャーバージョンアップで結構色々変わっているようですがその中でプラグインへの対応が大きく変わっています。今まではプラグインのファイルを所定のフォルダーに自力でコピーしていたのですが、この所定のフォルダーの位置がOSによって違うのはもちろんバージョンによってふらふらと移動したりしてなかなか厄介な事になっていたのですが、このあたりの面倒を見てくれる「プラグインとコンテンツマネージャー (PCM)」というものが標準装備になりました。
PCM ではプラグインの他に部品ライブラリやカラーテーマも同様に管理する事ができ、インストール/アンインストールをボタン一つで行う事ができます。
これで今後はプラグインなどのアドオン関係は全部PCMに管理を任せるという事になると思います。
という事で、以前作ったガーバーファイルをそのままPCBベンダーに送れる形にZip化するプラグイン "GerberZipper" をこの PCM に対応しました。
https://github.com/g200kg/kicad-gerberzipper
PCM の使い方の詳細はGitHubの方に書きましたが、メニューから"ツール" - "プラグインとコンテンツマネージャー"を起動するとプラグインの一覧が出てくるので、そこから必要なもののインストールを指示するだけです。
デフォルトの状態では KiCad のオフィシャルリポジトリしか登録されていませんので、リポジトリの管理画面で次のURLを追加します。
https://raw.githubusercontent.com/g200kg/kicad-pcm-repository/main/repository.json
これで "g200kg KiCad PCM repository" が選択できるようになり、GerberZipperのインストール/アンインストールが行えるようになります。
PCM の使い勝手はこんな感じで昔の手動インストールから考えると随分快適になりました。
ただしプラグインを作る側からみると PCM に対応した形にするのはなかなか面倒です。
ステップ1
* まずは肝心のプラグインを作ります。プラグインのAPI関係の資料は↓が最新のものだと思います。https://kicad-python-python.readthedocs.io/en/latest/
そもそもこの KiCad プラグイン開発に必要な情報が充分整っているとは言えない状況なので、色々と探りながらやる事になりますが。
ステップ2
* プラグインをパッケージにします。メタデータとアイコンを含めて次のような形でZipにまとめます。Archive root |- plugins |- __init__.py |- ... |- resources |- icon.png |- metadata.jsonメタデータの書式等の詳細は↓のページにあります。
https://dev-docs.kicad.org/en/addons/
ここで作ったパッケージは"プラグインとコンテンツマネージャ"の画面で"ファイルからインストール"によって直接インストールする事もできます。
また KiCad のオフィシャルリポジトリに登録の要望を出す場合もこの形式のパッケージを送る事になります。
ステップ3
* PCM の画面でリポジトリを指定してインストールできるようにするには、パッケージのリストを公開するためのリポジトリを用意します。複数のプラグイン(ライブラリやカラーテーマでも良いですが)を公開したい場合にはこういう形になります。詳細はドキュメントhttps://dev-docs.kicad.org/en/addons/を読めばわかると思いますが、repository.jsonやpackages.jsonに必要な項目にはsha256ハッシュやファイルサイズ、UTC時刻値などもあるので、プラグインのリリース作業ではプラグイン側のリポジトリを更新した後、PCM用リポジトリを更新する事になります。手数が多くなって手作業でやるにはちょっと面倒なので更新用のスクリプト的なものを書く方が良いと思いますが、それはそれで面倒。
Posted by g200kg : 9:45 PM : PermaLink
2022/01/13 (2022年01月 のアーカイブ)
WebSequencer のソース
もう10年近く前に Web 上の MIDI シーケンサー WebSequencer というのを書いて適当にサイト上に置いてあったのですが、ライセンスに関する問い合わせがあって、せっかくなので GitHub上に MIT ライセンスを明記して公開しました。
今となっては色々と古い部分があります。シーケンサー部とシンセ部が完全に分離していてiframeで組み合わせるようになっているのですが、最近のブラウザのセキュリティ面の強化により、音を出すにはユーザーからのトリガーが必要になり、ページ間をまたいで指示を飛ばせないので、シーケンサーとシンセをそれぞれ別にユーザーが起動をかける必要があるというのが特に問題です。
古いソースなので他にも色々と不都合はあるかも知れませんが、まあこれでも何かの参考になればと思います。
GitHubリポジトリ : https://github.com/g200kg/websequencer
動作ページ : https://g200kg.github.io/websequencer/
Posted by g200kg : 5:18 AM : PermaLink
2021/12/16 (2021年12月 のアーカイブ)
オーディオマニア向けイーサネットスイッチ
https://gigazine.net/news/20211215-ethernet-switch-for-audiophiles/
約26万円の「オーディオマニア向けイーサネットスイッチ」の話題。
オカルトだなんだと言われるこの手の話は昔からあるけど、自分的解釈としては聴いている人にとっては確かに良い音に聴こえるのだと思う。ただしその人にとってはという話。
プラセボと呼ばれては身も蓋もないが、音の良し悪しというのは聴覚刺激を脳がどう判断するかである以上、聴く時の精神状態に依存して感じる音が変化するのは当然だと思うし、良い音を感じやすいように精神状態を整えるのは意味があると思う。
同じ曲を長時間ミックスしていると同じ設定にしても場合によって全然違って聴こえるなんてのは普通の事。
同じ音源を聴いてもゴミ屋敷みたいな部屋で聴くのと良い音がでそうな部屋で聴くのとで同じ評価が下せるとは思えないし、自分の信じる一番良い音が出る機器を使うというのはある意味重要。人によっては一番良い音と感じやすくなる香りとか、料理とかもあるんだろうな。
脳が聴覚から受ける刺激の質を問うのであれば、そんな事よりもこの10年で加齢により可聴周波数の上限が数kHzは下がっている事の方がはるかに深刻ではある。人間の耳の特性は刻々と変化している。が、音の良し悪しは刺激を受け取った後の脳がどう判断するかという話なので、良い音を感じやすい環境は重要だとは思う。
そこにおかしな理論で無理に技術的裏付けを付加しようとして批判を受けるというのもありがちだけど。
まあ私は別にオーディオマニアではないので、基本的には気にしない。
Posted by g200kg : 8:21 PM : PermaLink
2021/12/07 (2021年12月 のアーカイブ)
耳の話の続き
先日、「耳の話」なんかを書いたのでその辺りの話をもう少し書いてみます。
耳の奥、蝸牛は AGC (Auto Gain Control) 機能付きの高性能アクティブセンサーである、みたいな話だったのだけど、その有毛細胞によるフィルタバンクで周波数分析された音声信号はそのままパラレルに脳のニューラルネットに入力されるわけですが、これってそのまま「スペクトログラム」なんですよね。横軸が時間、縦軸は周波数でどの部分にエネルギーが存在しているかを表すグラフです。あの声紋分析なんかで使われる奴です。
コンピュータによる音声認識でも同じように入力された音声はまず FFT とかで周波数分析しますが、問題はこのあとどう処理するかです。母音の判定をするためにフォルマントを抽出してみたりフォルマントの時間的な動きを抽出してみたり、音素を判定してみたり、HMM で辞書と比較してみたり、とこれまでに様々な職人芸的音声処理が試行錯誤されてきたのですが、徐々に改善はされるものの中々精度が良くならない、という時代がコンピュータの黎明期からずっと、50年近く続いていたわけです。この時代は多分認識の精度としては精々70%~80%くらいだったかと思います。フォルマントの動きを特徴量として抽出して隠れマルコフモデル(HMM)で判定するというのがこの時代の代表的なやり方でした。
そして音声認識というとあまり実用的じゃないなというのが実際の所の評価。アプリケーションを限定すれば使えるケースもあるかも知れない、という程度。認識を2択、3択等に限定すればそれなりに動くけど間違っても許してね、という感じ。
それが2000年代頃に登場したディープラーニングの応用でいきなり様相が変わります。DeepMind社のWaveNetとかですね。割とすぐにGoogleに買収されましたけど。今までより明らかに優れた認識精度! これは職人芸的な様々な判定手法じゃなく、とにかく抽出したフォルマントとかの特徴量をまとめてニューラルネットに放り込んで大量の学習データでぶん回せばなんとかなるんじゃないかという丸投げ方式ですが、これが今までの緻密にチューニングを繰り返してきたやり方をあっさりと上回る品質が出てしまったわけです。
そして更に10年ほど経った2010年代、再びショッキングな事実が明らかになります。
最終的な判定にニューラルネットを使うとしても、入力する前段階の処理としてこれまではフォルマントの動きやらを職人芸的手法で抽出していたのですが、もしかしてこれ、要らないんじゃね? と。そして周波数分析をした後のスペクトログラムをそのまんまニューラルネットにぶち込んでも学習さえちゃんとやれば動作するんじゃね? と。
そして案の定職人芸の敗北。周波数分析とニューラルネットだけを使って大量の学習データをぶん回す事で、より良い結果が出てしまいました。この構造は図らずも人間の耳から脳に周波数分析データをパラレルにぶっこんでる構造と同じ、職人芸的ロジックとかはどこにも入っていません。ある意味ずいぶんシンプルになってしまいました。ニューラルネットの中身というのは割とブラックボックスなのでミクロな視点で何がどうなってこういう結果が出るのかと言われると説明は難しい事になってしまいましたが、言葉を知らない赤ん坊が大量の言葉を聴いて覚えていくように人間がロジックをこねくり回すよりも自然現象として言葉をおぼえてしまう、みたいな事になっています。
シンギュラリティポイントの始まりみたいなものを感じますね。今後どうなるんでしょうね。
Posted by g200kg : 6:21 PM : PermaLink
2021/12/05 (2021年12月 のアーカイブ)
耳の話
聴力テストを作ったりしたので、ちょっと耳系の話も書いてみます。
人間が音を感じるセンサーになる部分は耳の奥、内耳にある蝸牛と呼ばれる器官です。なんとなくイラストを見たりした事があるかも知れませんがあのカタツムリみたいな奴、乗り物酔いの原因にもなる有名な三半規管とくっついている奴ですね。
鼓膜からの振動はこの蝸牛に伝えられるわけですがそこには数万個の有毛細胞があり、その内の3500個程度が内有毛細胞というもので機械的な振動に反応するようになっています。そしてそれぞれの内有毛細胞は特定の周波数と共振してここで周波数分析が行われます。これは言わば物理的なフィルタバンク、凄いですね。そして内有毛細胞からの信号はそのまま全部パラレル(!)に脳のニューラルネットに送り込まれるわけです。人間は音程には敏感だけど位相は殆ど認識できないというのはこういう構造で脳への入力信号がそもそも周波数毎のマグニチュードしかなくて位相情報が取れていないからなんでしょうね。
数万個の有毛細胞の内、振動に反応する内有毛細胞が3500個程度、すると残りの外有毛細胞と言われる部分は何なのかというと、この辺はまだ完全に動作が解明されていないらしいのだけど、どうやらセンサーではなくモーターらしいという興味深い事がわかっているようです。つまり刺激を受けて脳に信号を送るのではなく、信号を受けて能動的に動く。しかも音声信号レベルで高速に動いて自ら音を発している!! なんと!!
つまり耳が音を聴いていると思ったら耳から音が出ている!
このセンサーとモーターが組み合わさってどうやら信号の非線形な増幅装置が構成されているというのが定説となっています。このため、単体で摘出された蝸牛で何が起こっているのか確認しようと実験してもどう考えてもマイクとしての感度が低すぎる。生体の中でのみ稼働するアクティブセンサーらしいのです。
この耳から出てくる音は耳音響放射と言い、実際に耳に音を入力した時に耳から出てくる音を測定して内耳の機能検査などで使用されています。
人間の耳が音の大きさに対して対数的に反応し、ぎりぎり聴こえるかすかな音からジェット機の爆音まで120dBの幅の大きさの音に対応できるのはこのアクティブ機構があるからのようです。
凄すぎるだろ、耳。
Posted by g200kg : 5:51 PM : PermaLink
2021/12/04 (2021年12月 のアーカイブ)
聴力テストを作ったのだが...【悲報】12kHzが聴こえなくなりました
モスキート音、どこまで聴こえてますか?
という事で聴力テストを行うページを作りました。
GitHub に置いてあります。
実行ページ : https://g200kg.github.io/auditory-test/
リポジトリ : https://github.com/g200kg/auditory-test
再生環境にもよりますので正確とは言えませんが、目安にはなると思います。どうやらもう12kHzあたりが限界ぽいです。
加齢と共に高い周波数の感度が下がるのは今更どうこう言ってもしょうがない事なのだけど10年前くらいなら聴こえていたはずの音が聴こえないのは残念な話です。まあ所詮人間の耳なんてそもそも犬とかに比べると全然聴こえていないんですけどね。
耳の特性が変わっていくのだから同じ音源を聴いても脳が10年前と同じ刺激を受け取る事は出来ない、という事実についてオーディオマニアな人達はどう折り合いを付けているのだろうかとか思ったりはする。
ヘッドホンでガンガン音量を上げるのが好きな人とかは後で後悔するから程度を考えた方が良いです。
Posted by g200kg : 11:28 AM : PermaLink
2021/11/25 (2021年11月 のアーカイブ)
猫マナーのページ
行が傾いて見える有名な錯視の奴。
実際に傾けてみたくなったのでなんとなく作った。
逆に傾ければまっすぐに見えるんじゃないか、とか。
猫マナーのページ
Posted by g200kg : 1:22 AM : PermaLink
2021/09/01 (2021年09月 のアーカイブ)
Maker Faire Tokyo 2021 (MFT2021)のオンサイト開催は中止されました
2021年10月2~3日に予定されていたMaker Faire Tokyo 2021 (MFT2021) はオンラインのみの開催となり、東京ビッグサイトでのオンサイト開催は中止されました。
MFT2021のトップページにアナウンスが記載されています。残念ですが最近の状況ではしょうがないですね。
オンラインのイベントは予定どおりで現在企画やタイムテーブルを調整中とのことです。
https://makezine.jp/event/mft2021/
Posted by g200kg : 11:30 AM : PermaLink
2021/07/16 (2021年07月 のアーカイブ)
MFT2021 に出展します
昨年に続き、コロナ感染対策のため、基本的に展示物には触れられないといういささか不自由な展示にはなりますが、10月2~3日に東京ビッグサイトで開催される「Maker Faire Tokyo 2021 (MFT 2021)」に「Web Music Developers JP」名義で出展します。
チケットはまだ準備中のようですが、混雑を避けるため、昨年同様の入場日時指定方式になるようです。
まだしばらく先の話ですが、来場を予定されている方よろしお願いします。
イベント名称 : Maker Faire Tokyo 2021
日時 : 2021年10月2日(土) 12:00 - 17:00 (予定)
: 2021年10月3日(日) 10:00 - 16:00 (予定)
会場 : 東京ビッグサイト 南3ホール
入場料 : 大人 1000円、18歳以下 500円
Posted by g200kg : 12:03 AM : PermaLink
2021/07/06 (2021年07月 のアーカイブ)
W3C 勧告 「Web Audio API」 日本語訳を公開しました
先月、6月17日に「Web Audio API」が正式に W3C Recommendation (W3C 勧告) になりました。
今年の1月頃の勧告候補のあたりと比べると機能的な面では全く同じですが、細かな挙動などについて説明が追加されたりしています。例えば audioエレメントのサンプリング周波数が AudioContext のサンプリング周波数が違っている場合は Web Audio 内部でリサンプリングする、とか、オーディオグラフのレンダリングの内部動作の手順がより詳しく説明されたり、という感じです。
という事で、正式版「Web Audio API」の日本語訳を作りましたので公開します。
Web Audio API, W3C Recommendation, 17 June 2021 (日本語訳)
元文書である W3C のページはこちら : W3C : Web Audio API, W3C Recommendation, 17 June 2021
さて、これで W3C の文書としては最終形で、今後変更はされず固定されます。間違いなどが見つかった場合はこの文書の変更ではなく、正誤表 (errata) による対応になります。
errata のページはこちら : W3C : Errata in REC-webaudio-20210617/
また今後の仕様の拡張等については「Web Audio API v2」として GitHub の別リポジトリがありますのでそちらで議論が進められる事になるはずです。
Web Audio API v2 はこちら : GitHub : WebAudio / web-audio-api-v2
Posted by g200kg : 4:32 PM : PermaLink
2021/06/30 (2021年06月 のアーカイブ)
Web Audio API がW3C勧告標準に
ブラウザ上で音の生成や処理を扱う技術である「Web Audio API」が6月17日、ついに W3C の正式な勧告 (Recommendation) となりました。
ブラウザで音を扱う機能の実験的な実装が始まってからもう10年経ってます。Chrome の「Web Audio API」と Firefox の「Audio Data API」があってこれをどうやってまとめるつもりなのか、みたいな事をやってた時代から既に10年。とにかく動きが速い Web 技術界隈にあって、10年かけて W3C 勧告になるというのは一大事業感はありますね。
私が翻訳している「Web Audio API (日本語訳)」は内容としてほぼ W3C 勧告と同じではありますが、まだ勧告候補(Candidate Recommendation」 (1月14日スナップショット) のままですので、そのうちアップデートするつもりです。
なお、今回 W3C 勧告となった Web Audio API はバージョン1(v1) という位置付けであり、このまま引き続き機能の拡張等が行われる v2 の検討が始まっています。
Posted by g200kg : 4:53 PM : PermaLink
2021/05/28 (2021年05月 のアーカイブ)
光造形3Dプリンタでノブを作る
先日、光造形の3Dプリンタを導入したのですが、同梱されているテストデータすら出力せずにひたすらノブを出力しています。FDMでは無理でしたが光造形なら充分実用的なノブが作れます。
光造形の特性として出力時間は高さ方向のサイズにのみ依存し10個やそこらは一気に作れるので、洗浄やら二次硬化やらの後処理は面倒ではありますが、出力にかかる時間もまあ実用的な範囲内かと思います。
方向を示すマーキングは窪みを作っておいてラッカー塗料を面相筆で流し込む方法で付けていますが、これは細かいので多少気を使いますね。
ガジェットやシンセ等、作っていてツマミ類に困っている人にはオススメです。
・市販品に気に入ったものがない
・数が多いと意外と高くなる
・今後同じものが入手できるか不安
というあたりが一気に解決できます。
特にDIY系だと安い市販ノブを探しても選択肢が少なくて他の人とカブり勝ちで「あ、○○で売ってる安いノブを使ってるな」とか即バレしますのでそういうのも避けられます。
なおシャフトとの篏合はナールドのシャフト(ギザギザの奴)に嵌め込むタイプで作っていて、おそらくプリンタやレジンの種類によって多少の調整は必要と思われます。今のところシャフト径のジャストサイズ + 0.数mm 程度のあたりで丁度良い硬さになる所を探っています。多分 D シャフト(平軸) でもシャフト部を調整すれば嵌め込みで行けるかと思います。イモネジで締めるタイプが作れるかどうかはちょっとやってみないと分からないですね。
使用しているのは
プリンタ -- Nova3D BENE4 Mono
レジン -- Nova3D 水洗いレジン(黒)
モデリング -- Blender
スライサー -- NovaMaker
という環境です。
取り合えず4タイプほど使えそうなノブを作ってみたので、stlファイルが必要な方はこちらからどうぞ。
20210528_knobs.zip

Posted by g200kg : 6:14 AM : PermaLink
...更に以前の記事...
g200kg