g200kg Music & Software

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ホール)
主催 : 株式会社オライリー・ジャパン

私がブースに並べたのはギター風の楽器「SOROBAN v2.5」と電子ハーディーガーディー「ElectroGurdy」です。

佐藤ガジェット製作所さんのリアクティブエフェクター「Frigus RE-1」。ジャイロセンサーを搭載していてギターを傾けるとエフェクトが変化する。

Frigus RE-1 のアップ。かなり高機能そう。設定を詰めるのは大変かも知れない。

同じく山下さんの所では、0.96"OLEDと直結できるAVR64DB32使用の超小型Arduino互換ボードが置いてありました。

Quxさん。アナログシンセの基本的なモジュールのキットを売っています。入門用に良さそうです。

ピコケットでもお世話になったピコピコファクトリーさん。Prophet-5と同様の音源回路を持つオープンソースプロジェクト「ProFree-4」も着々と進んでいるようです。

奇楽堂さんのタッチキーボード。各鍵盤に静電センサーを搭載してあり、抑える位置により音を変化させたりできる。部品を載せた基板を鍵盤そのものにしてしまうというのはちょっと新しい。ROLIのSeaboard的な使い方ができそう。

necobitさん。黄色い人。MIDI経由でとにかく色んなものを動かすMIDI遊園地というコンセプトでそれに必要なモジュールを販売しています。

R-MONO Labさんの所にあったエレキモノサシ。定規でベース音を奏でるいわゆる「モノサシスト」になれる楽器でエレキ化されている。これは良い音。ピックアップはどうなっているのかと思ったらリレーのコイルを使ってハムバッキング化しているらしい。

タニウラさんのサーキットベンディングコレクション。音の出るおもちゃを改造した数々。写真を撮り忘れたけど、水槽の中におもちゃを入れてワイヤーで各部を引き出した展示の世界観的なヤバさが良かった。

カイワモノさんのたこ焼き屋台。たこ焼きをつつく度に音が出る。デモでは金属箔を丸めたものをつついていましたが、実際にたこ焼きを焼きながら音を出す事もできるそうです。

ひたすらArduino Unoをしゃぶり尽くす ISGK Instrumentsさん。最近は RasPi Pico なんかにも手を出しているようだけど Arduino Uno でもまだやる事が残っているらしい。

熊本大学上瀧研究室さん。半自動楽器によるデモ演奏。運指は全部自動的にやってくれるのでタイミングを合わせて弦を弾いたり息を吹き込むだけで演奏できる。

半自動楽器のギターのフレット部分の拡大。フレットを押さえるのはソレノイドではなくサーボを使っているようだ。なるほど。

久しぶりのオンサイトイベントですが、結構盛況だったと思います。
なお、展示した「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月のアーカイブ)

ハーディーガーディーのキットを作ってみた

「ハーディーガーディー」という楽器をご存じでしょうか。
変な楽器好きの人なら知っているとは思いますが、ざっくり言えばバイオリンのような弦楽器がちょっと変な方向に進化したような楽器で、弓で弦を弾く代わりに手回しハンドルで回転する円盤で弦を擦って持続音を出す事ができる楽器です。また、メロディを演奏する旋律弦に加えて持続音を出すドローン弦が張られていますので、音の雰囲気としてはバグパイプにも近い部分があります。

かなりレアな楽器なので本物にはなかなかお目にかかれないのですが、アマゾンとか楽天でハーディーガーディーの模型が売られているのを時々目にします。これは、単にハーディーガーディーをかたどった置物的なものだと思って完全にスルーしていたのですが、ちゃんと組み立てれば一応音が出る状態になると最近知って買ってみました。ミニチュアですけど、なかなか凝った装飾がされています。

中身はレーザーカットされたMDF材が8枚。他に可動部分に塗るロウとか弦とか弦を擦る部分用の松脂。結構なボリュームです。

これ、メイドイン・ウクライナなんですね。ちょっと情報を追ってみると、ユーギアーズの社員は現在無事だけど、生産活動は停止中という事らしいです。

説明書は一応日本語も書いてありますが、そもそも文章はほとんど無くて基本的には図で説明されています。ところどころロウを塗る場所とかペーパーで磨く所とかのアイコンが付いているのでアイコンの意味だけは把握しておいた方がよさそうです。

また、組み立てに使用できるハンマーのキットが付属しています。本番に取り掛かる前のチュートリアルとしてちょうど良い難易度です。ただしさすがにハンマーとして使うには軽すぎなので別途ゴムハンマーとかがあった方が良いかも。というか最初はハンマーを組み立てるためのハンマーが無いですね。

という事で組み立てていきます。ボディ部分ができた所。接着剤も使わず、すべて木製部品をハメ込んで行くだけです。結局、レーザーカットされたMDF材から部品を取り出すのが一番手間がかかり、非常に繊細な構造なので変に力を入れると部品を壊しそうです。

完成しました。気楽にプラモデルを作るくらいの感覚でざっと数日分くらいの作業量ですかね。

では実際にテストします。ぎりぎり音が出ているという感じですが、弦がただのテグスっぽいのでこの辺をちゃんとすれば音色としてはもっと良くなりそうな気はします。

一応音は出ますが、本格的な楽器として使う感じのものではありません。しかしこれだけ可動部分のある構造物を木製パーツのハメ込みだけで接着剤も使わず作れるというのはなかなか凄い事だと思います。構造を知るという意味ではとても興味深いものでした。

[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

Ugears ユーギアーズハーディーガーディー 70030 Hurdy-Gurdy 木のおもちゃ 3D立体パズル知育ウッドパズル工作キット木製模型キットつくるんです
価格：9554円（税込、送料無料) (2022/4/28時点)

楽天で購入

ではここでお気に入りのドイツのハーディーガーディー奏者、Patty Gurdy、ソロライブ版。ハーディーガーディーの妙にメカメカしい感じが凄く良い。

ドイツの中世風コンセプト(メディエバルメタルと言うらしい)のバンド、ダルタニアンとのコラボ。良い。

Posted by g200kg : 12:35 PM : PermaLink

2022/04/21 (2022年04月のアーカイブ)

第一回Pikoketが開催されました

先週の話になってしまいますが、4月16日(土)に電子工作者&シンセビルダー同人展示即売会「ピコケット」Pikoketが開催されました。場所は北の丸公園の科学技術館です。

第一回の開催という事でどんな感じになるのかよく判らずに参加したのですが、シンセ関係6割電子工作関係4割くらいのイメージですね。コロナ禍以来のオンサイトイベントという事もありちょっと様子を探りつつという所もありましたが、人が密集するというほどでもなく適度な混み具合だったと思います。

一部ですけど、展示物の様子など。

木目塗装にした奴が本当に木製だと思っていただいた方もいて、塗装技術に自信がついたのが収穫。

主催でもあるPikoPiko Factory さんの PROFREE-4。名機Prophet-5の音源回路をそのまま採用し、制御系はデジタル化して再現するというオープンソースハードウェアプロジェクトです。

同じくPikoPiko Factoryさんの小物。「Q電くんβ」はMIDI-DIN端子から無理やり給電するタイプのBT-MIDIアダプタに外部から給電する機器。かけはしMIDIはMIDI-TRS規格の混乱を吸収するための変換アダプタです。

ねや楽器さん。シンセの出力波形を利用してサーボモーターを駆動する試み。この奥にあるのはサーボモーターでシンセのノブを動かすセットアップになっている。

ISGK Instrumentsさん。いつものようにArduinoを骨までしゃぶるシンセを展示していたけど、最近はRaspberry Pi Picoにも手を出しているようだ。

SOUNDGAMEさんのユーロラック仕様のモジュール。8ビットゲーム系の音が出るようだ。

まだまだリアルイベントを開催するには厳しい環境ですが、そろそろとこういう催しも復活しつつあるようです。まあ今後の状況次第ではありますが。

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円）の購入が必須です。

https://pikoket.seesaa.net/

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円

MFT 2021 公式ページ

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 勧告になるというのは一大事業感はありますね。

W3C プレスリリース

W3C Web Audio API

私が翻訳している「Web Audio API (日本語訳)」は内容としてほぼ W3C 勧告と同じではありますが、まだ勧告候補(Candidate Recommendation」 (1月14日スナップショット) のままですので、そのうちアップデートするつもりです。

Web Audio API (日本語訳)

なお、今回 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

最近の記事