RSS Twitter Facebook
DTM / シンセサイザー / VST / WebMusic 関係の技術情報を発信しています
シェア



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
AideepenGND VCC SCL SDA27.5 x 27.823.5 x 23.84-φ2.0amazon
VKLSVANGND VCC SCL SDA25.2 x 26.0021.00 x 21.84-φ2.0amazon
ResbeeGND VCC SCL SDA27.5 x 27.823.5 x 23.84-φ2.0amazon
KeeYeesGND VCC SCL SDA25.4 x 26.121.8 x 22.64-φ2.0 (推測)amazon
WinstarVCC GND SCL SDA26.7 x 19.2620.7 x 23.24-φ2.5winstar
EShineVSS VDD SCL SDA27.3 x 27.823.3 x 23.84-φ2.54made-in-china
LYGND VCC SCL SDA27.2 x 27.221.74 x 19.264-φ2alibaba
FriendlyElecSDA SCL 5V GND27.3 x 27.320.7 x 23.2φ? (横長穴)friendlyElec
ZEKEVCC GND SCL SDA27.3 x 27.320.7 x 23.24-φ? (横長穴)rakuten
IZOKEEGND VCC SCL SDA25.4 x 26.120.7 x 21.54-φ?amazon.ca
EasyWordMallVCC GND SCL SDA27.3 x 27.320.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材から部品を取り出すのが一番手間がかかり、非常に繊細な構造なので変に力を入れると部品を壊しそうです。

左手で操作するキー部分。

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

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

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


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

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


Posted by g200kg : 12:35 PM : PermaLink

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

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


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

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

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

入口の表示はこんな感じ。科学技術館6Fの第3会議室です。

私が持ち込んだのはこれ。謎楽器soroban v2.5です。

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

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

PROFREE-4全景。4音ポリ、ミニ鍵37キーです。

同じく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

2021/05/05 (2021年05月 のアーカイブ)

3Dプリンタで穴が小さくなる問題


3Dプリンタで使うスライサーのアップデートをずっとさぼっていて気がつかなかったのだけど、FDM 方式の宿命のように言われていた穴の径が設計よりも小さく出力される問題も既に過去のものになったようです。

これはモデルの外形を幅のあるストロークで引いているために原理的に発生するもので、穴の形状を描いた時にフィラメントは円の内側にもはみ出すため、一般的な 0.4mm のノズルなら穴の直径も 0.4mm ほど小さくなるというものです。

スライサーに Cura を使っている人は既に知っているのかも知れませんが、家で使っているのが QIDI のプリンタで、オフィシャルのスライサー(Cura のカスタマイズ版) を昨日アップデートした所、設定項目が増えていたようです。エキスパートモードの「アタッチ」タブに「Hole Horizontal Expansion」という項目があり、これで穴を開けた時の径を補正できます。

面倒くさくなったのかここだけ英語のままなので逆に目立って存在に気が付きました。

今までは穴をモデリング時に大きめにして置くしかなく、作ったデータを精度の良いプリンタに持って行きたい時にとても面倒な事になっていたのですが、これで随分快適になります。Φ3.2 で穴を作っても Φ2.8 になってしまって M3ネジが通らないとか悲しい状態だったので。

今のところ QIDI のプリンタで使っている設定は上の図の通りです。

注意すべきはその上の「水平展開(Horizontal Expansion)」で、これはモデルの水平方向の外形を伸ばしたり縮めたりを微調整するパラメータです。家のプリンタだとモデル全体の外形が微妙にサイズ足らずで出力されるのでこの設定を +0.1mm で使っていたのですが、穴径はこちらの影響も受けます。

なので上の図のように水平展開が 0.1mm で Hole Horizontal Expansion が 0.3mm だとすると、穴の直径は水平展開によって 0.2mm 小さくなり、Hole Horizontal Expansion によって 0.6mm 広がるので、結果穴の直径は 0.4mm 大きくなるという事になります。

直径 3mm で開けた穴に M3ネジが通るし、直径 6mm で開けた穴には Φ6 のシャフトが通る!!

なお、これはあくまで穴になっているかどうかを判断して補正が掛かっているので、下の図のように板の耳に切り欠きを入れてネジ止めしようというような形状の場合は補正が掛かりません。今まで通りモデリング時に余裕を持たせるしかないですね。


Posted by g200kg : 9:35 AM : PermaLink

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

Arduino Nano Every のADC入力を増やす


Arduino Nano の後継として Arduino Nano Every が発表されてからもう2年くらいですね。
MCUが ATMega328P から ATMega4809 に変わり、安くなって性能も上がっているのですが、それほど使われてないですかね? レジスタ直叩きとかし始めると 328P との互換性が無いのがネックかも知れません。 でも ATMega4809 だから出来る事もあります。

と言う事で、ADC入力ピンを増やす例です。

注 : ATMega4809 ではなくピン数の少ない ATMega4808 を搭載した Arduino Nano Every の廉価版互換機も存在するようです。この手法は ATMega4809 でしか使用できません。

Arduino Nano では A0～A7 の 8本のピンをADC入力として使えますが、ATMega4809 では本来 16 本のピンを ADC 入力として使う事ができます。ただしその内の 1 本はピンとして引き出されていませんので、トータル 15 本のピンをA0～A14として使う事が可能です。

なお、A9 (D13) ピンは Arduino 内部で LED に繋がっているのでちゃんとは使えないかも知れません。

ソースは下の通り。A8～A14 に対して pinMode を入力にして、analogRead4809() を呼べば A0～A7 に対する analogRead() と同様にアナログ値を読む事ができます。括弧内の (AIN7) 等は 4809 のピン機能の名前です。

Arduino Nano ベースで作っていて ADC 入力の本数が足りない、と言う場合には便利かも知れないのでメモ。 


/*    ARDUINO-NANO-EVERY ADC Pins
 * 
 *             ___________________
 * (AIN10) A9 |D13    |____|   D12| A10 (AIN9)
 *            |3V3             D11| A11 (AIN8)
 * (AIN7)  A8 |AREF(D39)       D10|
 * (AIN3)     |A0  (D14)        D9|
 * (AIN2)     |A1  (D15)        D8| A12 (AIN11)
 * (AIN1)     |A2  (D16)        D7|
 * (AIN0)     |A3  (D17)        D6| A13 (AIN14)
 * (AIN12)    |A4  (D18)        D5|
 * (AIN13)    |A5  (D19)        D4|
 * (AIN4)     |A6  (D20)        D3| A14 (AIN15)
 * (AIN5)     |A7  (D21)        D2|
 *            |5V              GND|
 *            |RES             RES|
 *            |GND              RX|
 *            |VIN              TX|
 *             ~~~~~~~~~~~~~~~~~~~
 */

#define A8  (39)
#define A9  (13)
#define A10 (12)
#define A11 (11)
#define A12 (8)
#define A13 (6)
#define A14 (3)

int analogRead4809(int pin){
  static uint8_t aintab[] = {15,0,0,14,0,11,0,0,8,9,10,3,2,1,0,12,13,4,5};
  int ain = 0;
  if(pin==39) ain = 7;
  else if(pin>=3 && pin<22)
    ain = aintab[pin-3];
  if(ain==0)
    return 0;
  ADC0.MUXPOS = ain;
  ADC0.COMMAND = 1;
  while(!(ADC0.INTFLAGS & ADC_RESRDY_bm))
    ;
  return ADC0.RES;
}

void setup() {
  Serial.begin(9600);
  pinMode(A8,INPUT);
  pinMode(A9,INPUT);
  pinMode(A10,INPUT);
}

void loop() {
  int a8val = analogRead4809(A8);
  Serial.print("A8 :");
  Serial.println(a8val, DEC);
  
  int a9val = analogRead4809(A9);
  Serial.print("A9 :");
  Serial.println(a9val, DEC);

  int a10val = analogRead4809(A10);
  Serial.print("A10 :");
  Serial.println(a10val, DEC);

  delay(1000);
}

Posted by g200kg : 8:29 AM : PermaLink

2021/03/10 (2021年03月 のアーカイブ)

[Windows] マイク配列とは何なのか?


Windows を使っている人ならデバイスの選択とかで一度くらいは見た事があるかも知れない「マイク配列」という単語。これ何ですかね?

デバイスとして選択すれば普通にマイクとして機能するのでついスルーしてしまいがちで、私も「マイク」と「マイク配列」の違いについて真面目に調べたのは割と最近です。

それで「マイク配列」という言葉だと耳慣れないのだけど、実は英文ドキュメントの方だとこれは「マイクアレイ(Mic Array)」になっています。 いや確かに直訳すればそうか、と思うが「マイクアレイ」ならだいたいの想像が付くのだがなあ。

つまり、複数のマイクを並べて信号処理によって指向性を付けたりする奴ですよね。

「マイク配列」という言い方は Windows のドキュメントくらいでしか見ないので何か別のものだと思っていました。そして「マイク配列」の正体についてちゃんと説明されているドキュメントがほとんど見つかりません。日本語なら「マイクアレイ」の方が通じると思うのだけど今更手遅れかなあ。

結論から言えばユーザーから見た場合は「マイク配列」は単にマイクの一種なので違いについて気にする事は基本的にありません。違いがあるとすれば ( Windows の ) マイク配列は、人の声を録る事を主な目的としてチューニングされているので高音質の音楽を録音するような使い方は向いていない、そして専用のドライバー等(専用の設定アプリとか)で特性(指向性とか)の切り替えの機能があるかも知れない、という事くらいです。

「マイク配列」という言葉が Windows のデバイスの設定画面に登場したのは Windows Vista からになります。マイクアレイの信号処理と言うと外部に DSP を持ってそこで処理するというイメージが強いですが、なぜ OS がマイクの構造であるマイクアレイを気にするようになったのかというと、Windows Vista 以降では、マイクアレイに必要な信号処理をメインの CPU がドライバ内で肩代わりできるようになったからです。

Windows Vista がまだ Longhorn と呼ばれていた頃の Microsoft の資料にこんなのを見つけました。なるほどなあ。これが「マイク配列」の正体か。「マイクアレイ」ならこんな謎単語感はなかったのだがな。
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/ivantash-twen05009_microphone_array_support_in_windows_longhorn.pdf

ノートPCの内部はマイクを設置する環境としては劣悪ですが、とにかく画面の前にいる人の声を録るという用途であればマイクアレイと信号処理で余計なノイズを軽減できるというわけですね。ノートPCにマイクとおぼしき穴が複数付いている機種がありますがこれは別にステレオマイクというわけではなくてマイクアレイで信号処理を行うためのものです(機種によって例外はあるかも知れません)。

なお、マイクアレイにより指向性を持たせる際には、周波数特性は犠牲になります。対象が人の声だからこそ、その周波数帯に合わせてチューニングされているわけで、ハイファイな録音には向いていない事は知っておいたほうが良いでしょう。

※ ところで、上のデバイス一覧の画像で「マイク配列」として見えている BSWHD06 つてこんな感じのすごく安い Web カメラです。

どう見てもマイクアレイには見えないのだが......

分解してみた。やっぱりマイクひとつじゃねーか。

なぜこれが「マイク配列」扱いなのかは謎です。WebCam デバイスのマイクだと何か事情が違うのか? あるいはディスクリプたのコンフィグレーションが適当なのか?

Posted by g200kg : 7:00 AM : PermaLink

2021/02/25 (2021年02月 のアーカイブ)

WebHID API 日本語訳を公開しました


3月に安定版になる Chrome 89 では、フラグ設定なしで使用可能になる ハード系 Web API として Web Serial API と並んで WebHID API があります。
* なぜ "Web HID API" でなくて "WebHID API" なのか? 統一して欲しいな。

先日 Web Serial API を日本語訳したのですが、ついでに WebHID API も日本語にしたので公開しておきます。
Web Serial API と同じく WICG (Web Platform Incubator Community Group) のドラフトレポートです。
分量は Web Serial API と比べてもかなり小規模な内容です。

元文書 : https://wicg.github.io/webhid/

日本語訳GitHub : https://github.com/g200kg/webhid-api-ja/
日本語訳公開URL : https://g200kg.github.io/webhid-api-ja/
手引書 : https://g200kg.github.io/webhid-api-
ja/EXPLAINER.html

Web USB API も GamePad API もあるのに WebHID API は何を目指しているのかと言うと、 USB HID で接続されるニッチなデバイスを Web アプリから動かすのが目的になっています。 GamePad API はあくまでも共通規格を目指しているので各種コントローラーに共通なボタンやらセンサーやらを同じやり方で扱うのが目的ですが、WebHID では機種毎にバラバラなセンサーやバイブレーション機能等を扱うのが目的です。

規格の中身は、はなから機能の共通化は無理なので、コマンドの通り道だけ準備するから機種個別に勝手にやってくれ、みたいな内容で、ほとんど説明なしに、インターフェースとサンプルだけどかんと置いて、この辺りを触るのはどうせマニアックな奴しかいないからこれだけで分かるだろ、的な感じがもうなんか面白いかも知れない。

キーボード側に搭載されているコントローラーのキーマップを Web アプリから書き換える試みなんかもやられている模様です : https://www.eisbahn.jp/yoichiro/2020/12/webvia.html

Posted by g200kg : 3:29 PM : PermaLink


...更に以前の記事...


g200kg