g200kg Music & Software

RFリモコンの割と残念な連携

家には結構以前から Nasnos 製の電動カーテンを導入しています。電動ブラインドやカーテンの老舗ブランドです。特に必要があったわけでもないのですが面白そうだったので。これ、以前にニトリの電動カーテンとして OEM 供給されていたようなので同じものを持っている人はそれなりにいるんじゃないでしょうか。

これでリモコンによる開閉とタイマーによる朝夕の開閉が自動化できるのですが、残念ながら Amazon Echo などの AI スピーカーとの連携には対応していません。問題はこのリモコンが良くある赤外線リモコンではなく 315MHz帯を使うRFリモコンという奴で、そのため学習リモコン系のスマートホーム連携用のブリッジ等が使えません。

更にこのリモコン送信機は技適マーク付きの小電力無線機器になっています。こうなると送信機を改造する事もできず、厳密には分解した時点で二度と電波を出してはいけないので、解析もままなりません。AIスピーカーがブームになってから、そのうち Nasnos でも対応するのではないかと思って期待しつつ待っていたのですが、残念ながらその兆しもありません。

そうこうしている内に他社から AI スピーカー対応を謳った電動カーテン製品が出てきたのですが、その中のひとつ、LinkJapan 社製の電動カーテンを見て理解しました。「これメカ的には Nasnos のものと同じ」。つまり Nasnos がメカを供給して LinkJapan が AI スピーカー対応部分を作っている、と。Nasnos ではもう自社製品として AI スピーカー対応をする気がないのではないかという気がします。しかし LinkJapan の製品はもちろん別会社の別製品なので AI スピーカー対応部だけアドオンできるようなものでもなく、LinkJapan に乗り換えるなら Nasnos 製品を捨てて全取っ換えしかないし、ほとんど同じものを買いなおすというのも気が進みません。いや、Nasnos のメカ部分は結構長く使っていますがへたりも無く、優秀なんですよ。

取りうる手段としては物理的にリモコンのボタンを押すか同じ信号を小電力無線ではなく微弱無線で出す機器を一から作るか、くらいしかなさそうです。という事で、残念な方法ではありますが現実的な解としては、物理的にリモコンのボタンを押すというので良いんじゃないかなという気になってきました。スイッチボットのボタンを押す奴なんかもありますしね。

で作ったのがこれ

スイッチボットの指ロボット2つでリモコンのキーを押します。押す位置の調整が思ったより微妙で、輪ゴムで押さえる力の調整をしてなんとか動いている状態です。まあ動いているから良いかと思いますが。

なお、もう少しちゃんとしたものを作るのなら、電波を解析して信号をクローンし、Strawberry Linux で売っているこの辺のモジュールを使って送ればなんとかなるかもしれません :

微弱無線モジュール（３１５ＭＨｚ送信）

とりあえず現状のでも動いてるし面倒なのでやらないですけど、誰か作らないですかね。

Nasnos
LinkJapan

Posted by g200kg : 3:11 AM : PermaLink

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

Philips Hue 分解

家の電球をスマート電球、Philips Hue 化して半年、どうやら10球中の1球が死亡した模様です。せっかくなので中身を見てみたいですね。

Philips Hue の電球です。これは色の変化なしのバージョンです。電球が直接 Bluetooth、Zigbee の電波を飛ばすので技適マークがついています。

かなり硬い材質の半透明部分をなんとか切り取りました。LED がアルミ基板上に24個実装されています

メイン基板の裏にも結構な部品があります。ちょっと煤けた感じはするけど、見た感じでは特に重大な問題はない様子です。

無線基板を拡大。どうやら MCU はシリコンラボの EFR32 Wireless Geckoです。枝番がかすかに読み取れるのは「MG13P8」かな。なんだか基板のシルクが汚いですね。元々アウトレット品だったせいでしょうか。

中が見たくなったのでいきなりバラしてしまいましたが、冷静になって考えると無線の設定が吹っ飛んだだけで設定をやり直せば正常に戻ったのかも。後の祭り。高い電球なんだから半年で壊れるのはちょっと勘弁です。

Posted by g200kg : 11:03 AM : PermaLink

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

Arduino Nano Everyで高速PWMする例

Arduinoをそのまま組み込みで使う時にNanoを良く使ってたのだけど、そろそろ新機種である Nano Every に主力を移すべきかと思ったりもするのですが、完全に上位互換というわけではないので結局はケースバイケースかなと思います。

	Arduino Nano	Arduino Nano Every
MCU	ATMega328p	ATMega4809
Flash	32KB	48KB
SRAM	2KB	6KB
EEPROM	1KB	256B
クロック	最大16MHz	最大20MHz
USBコネクタ	USB Mini	USB Micro
価格	純正品なら Nano Every の方が安い。※ただし互換品を探すと Nano の方が安い。
互換性	Arduino IDE ベースでの互換性はそこそこ。タイマー周りはちょっと怪しい。

MCUが違うのでしょうがないのだけど、特にレジスタ直叩きでオーディオ周波数の波形生成なんかをしている場合は Every に移植するのは結構面倒です。という事で、Nano Every で高速PWMによるサイン波生成のサンプルをメモしておきます。

ATMega4809 のタイマーは TCA というのが1つと TCB というのが4つで 328P とは全く構成が異なります。クロック 16MHz を TCA0 で 512 カウントしてサンプリング 31.25kHz、9bit、これに PWM をかけて 440Hz サイン波を生成します。出力は Pin9 (PB0) 固定。

レジスタの定義はどこかでされているような気がするけど、取り合えず ATMega4809 のデータシートを見ながら全部このファイル内に置いてみました。


// Sin Wave Generation for Arduino-Nano-Every
#define PORTMUXBASE (0x05e0)
#define TCA0BASE (0x0a00)

#define TCAROUTEA (*((uint8_t*)(PORTMUXBASE + 0x04)))
#define TCA0CTRLA (*((uint8_t*)(TCA0BASE + 0x00)))
#define TCA0CTRLB (*((uint8_t*)(TCA0BASE + 0x01)))
#define TCA0CTRLC (*((uint8_t*)(TCA0BASE + 0x02)))
#define TCA0CTRLD (*((uint8_t*)(TCA0BASE + 0x03)))
#define TCA0PER (*((uint16_t*)(TCA0BASE + 0x26)))
#define TCA0CMP0 (*((uint16_t*)(TCA0BASE + 0x28)))
#define TCA0CMP0BUF (*((uint16_t*)(TCA0BASE + 0x38)))
#define TCA0INTCTRL (*((uint16_t*)(TCA0BASE + 0x0a)))
#define TCA0INTFLAGS (*((uint16_t*)(TCA0BASE + 0x0b)))
#define TCA0OVF_vect  _VECTOR(7)

float fdelta = 440.0 * 512 / 16000000.0;
uint16_t phase = 0;
uint16_t delta = (uint16_t)(fdelta * 32768);

int16_t sintab[512];

void setup() {
  for(int i=0; i<512; ++i){
    sintab[i] = 256 + sin(3.14159 * 2 * i / 512) * 255;
  }
  pinMode(9,OUTPUT);                // Pin9=Output
  TCAROUTEA = 0x01;                 // TCA0 PWM to PORTB
  TCA0CTRLA = 0x01;                 // PRESCALE : CLKSEL = fclk_per, peripheral Enable
  TCA0CTRLB = 0x13;                 // CMP0EN, SINGLESLOPE
  TCA0CTRLD = 0;                    // SPLIT mode=off
  TCA0INTCTRL = 0x01;               // Enable TCA0 OVF interrupt
  TCA0PER = 511;                    // Counter period = CLK / 512 (16MHz:31.25kHz or 20MHz:39.0625kHz)
  TCA0CMP0BUF = 100;                // PWM Value (0 - 511)
}
ISR(TCA0OVF_vect){
  TCA0INTFLAGS = 1;                 // Clear Interrupt
  phase += delta;
  if(phase >= 32768)
    phase -= 32768;
  TCA0CMP0BUF = sintab[phase >> 6]; // Set PWM value
}
void loop() {
  // put your main code here, to run repeatedly:
}

結果 : Pin9 出力に RC 一段入れただけなのでキャリアが乗ってしまっているけどこんな感じ。

Posted by g200kg : 10:14 AM : PermaLink

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

組み込み系ArduinoのKiCAD用ライブラリ公開

組み込みにそのまま使えそうな 600mil 幅の Arduino の KiCAD 用のライブラリを 3D モデル付で公開しました。
Arduino Micro、 Arduino Nano、 Arduino Nano Every、 Arduino Pro Mini、 Sparkfun Pro Micro の 5 種類です。

GitHub に置いてあります。
https://github.com/g200kg/kicad-lib-arduino

ライセンスは Creative Commons CC0 にしてありますのでご自由にどうぞ。

KiCAD では GitHub から直接フットプリントを読み込むこともできますが、反応速度の問題もありますので、ローカルにコピーして自分の環境に合わせてパス等を設定する方がおすすめです。

なお、3D モデルは .x3d フォーマットです。KiCAD の推奨フォーマットは .wrl なんですが .x3d でも問題なく読み込めます。Blender でモデルを作る時は .wrl を直接吐けないので .x3d で出力するのが良さそうです。

シンボル

フットプリント

3Dモデル

Posted by g200kg : 2:10 AM : PermaLink

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

メイカーフェア東京(MFT2020)が開催されました

久々のオンサイトのイベントでしたが無事終了しました。

日時 : 10月3日～4日
会場 : 東京ビッグサイト

原則として展示物には触れられないという事でもどかしい所はありましたが、流石に今はしょうがないですね。
入場日時の指定で人の密度はきっちりと管理されていたと思います。

以下大体楽器関係だけですけど、気になったものとか。

Web Music Developers JP のブース。毎度の事ながら割と適当。メイカーフェアへの出展は今回が初です。

隣のブースにあった例のチキンを楽器にした奴。コンプレッサーで溜めた空気を送り込んでいました。送り込む風量でピッチが変化するとか。そうなのか

これはモックらしいけど、コンパクトなProphet-mini。モックの完成度が高すぎる。中身の回路は偽物ICをつかまされて直前に火を噴いたとか...

Canvas:ノイズパフォーマンス。リアプロジェクションの効果が素晴らしい。音の発生源は米本実氏のヨネミン相当のものらしい

ESP32と気圧センサーを使ったウインドシンセ AFUUE。マジ楽器を目指している感じが良い

MIDI自動演奏システム。ゴムベースが良い味を出しているんだけど、どうやらチューニングが結構大変とか。まあそうか

ゼロからニキシー管を作る人。海外のYouTubeでこんな事をやってる人がいたけど日本にもいるもんだな

叩くとなおるテレビ。そういえば最近の子供はアナログテレビを知らないので砂嵐画面を見るとオカルト現象だと思うとか。このネタはいつまで通用するのだろうか。

Posted by g200kg : 7:37 PM : PermaLink

2020/09/25 (2020年09月のアーカイブ)

メイカーフェア東京2020に出展します

10月3日(土)、10月4日(日) は東京ビッグサイトで開催される Maker Faire Tokyo 2020 に Web Music Developers JP 名義で出展します。

今回のメイカーフェアはコロナの影響で密集を避けるためチケットはすべて入場日時指定制です。会場での当日チケットの販売は無いという事なのでご注意ください。

ブースの場所は会場の一番隅っこのようです。

https://makezine.jp/event/mft2020/

謎楽器公開予定

Posted by g200kg : 3:50 AM : PermaLink

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

KiCadのプラグイン環境について

このところ基板CAD、KiCad のプラグインを書いてみたりしていた訳ですが、タイミング的にあまり良くなかったというのもありますが、これはなかなか厳しい環境のようです。

KiCad の対応プラットフォームはWindows、Mac、Linuxの三種類あります。現在の状況としては安定版最新リリースがバージョン5.1.6、Nightlyビルドは現在 5.99、そして6.0リリースの準備が進められています。

プラグインはPythonで書けるのですがプラットフォームの OS の違いやバージョンの違いによって挙動がかなり異なります。

安定版の KiCad 5.1.6 に搭載されているPython、およびグラフィックスライブラリは

Windows　Python 2.7.16 wxPython 3.0.2.0 msw (classic)
Mac だと Python 2.7.16 wxPython 3.0.2.0 osx-cocoa (classic)
Linux だと Python 3.6.7 wxPython 4.0.1 gtk3 (phoenix)

同じ安定版 5.1.6 ですが Python の 2.X 系と 3.X 系が混ざっているのが辛い所です。気を付けて両方で動くように書くしかないですね。また Win と Mac はバージョン番号こそ同じですが、グラフィックスライブラリのウィジェットの大きさや細かな挙動が違うのでどちらでも画面が崩れないようなレイアウトが必要です。

また現在の安定版 5.1.6 と Linux 版の Nightly build (5.99) では Python のプラグイン API に割合積極的な変更があり、今まで使えていた API が無くなっていたりします。同じメジャーバージョン内ですが後方互換はありません。

更にその後のメジャーアップデートである 6.0 については現在 RC 版がありますが、9月中に機能をフリーズして年内をかけてバグフィックスという予定のようですので、まだプラグインを突っ込んでどうこうできる状態ではなさそうです。

という事で、今現在、大体どこでも使えるプラグインを作ろうとすると少なくともバージョン 5.1.6 の Win、Mac、Linux、そして Linux Nightly 版での動作確認が必要になります。まあそれ以前に API が流動的なのもあってちゃんとしたドキュメントが無いというのが致命的に効率が悪いのですが。

APIのドキュメントとしては下のdoxygenで吐かれたクラス名やメソッド名の一覧からあたりを付けて実際に試すかソースを読むしか方法がなさそうです。(とは言え、KiCad のプラグインには期待しているんですよ。とにかくもう少し安定してくれれば)

https://docs.kicad-pcb.org/doxygen-python/annotated.html

Posted by g200kg : 3:54 AM : PermaLink

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

[KiCad] GerberZipper : ガーバー/ZIPファイル作成の自動化

KiCad で作成した基板を業者に発注する際には、それぞれの業者向けの設定でガーバーを出力しZipでまとめる必要があります。これが発注先によって拡張子を変更したり設定を変えたりとなかなか面倒くさくて、添付忘れしたり設定を間違えたりという危険もあります。

という事で、発注先を選択するだけで必要なファイルを作成してZipにまとめるまでを自動的にやってくれる Python スクリプトを書きました。以前にも似たようなものを作っていたのですが、発注先の選択などができるように大幅に書き換えました。

起動すると発注先の選択をして、作成のボタンを押すだけで必要な Zip ファイルができます。

GitHubに置いてあります:
https://github.com/g200kg/kicad-gerberzipper

使用法

pcbnew のメニューから起動します。

発注先を選択して、作成ボタンを押すだけ:

とりあえず、各業者の推奨設定を見ながら
Elecrow / FusionPCB / JLCPCB / P板.com / PCBWay
の設定ファイルを作りました。
(※ 出力されるファイルは確認しましたが、全てのケースで実際に発注して大丈夫かどうか確認したわけではありません)

設定は json ですので、自分で書いて選択肢を追加する事もできます。
設定の詳細はこんな感じで確認できます。

Posted by g200kg : 6:30 PM : PermaLink

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

KiCadのガーバー出力オプション詳細

この辺に興味があるのは世界で10人くらいしかいなさそうなので自分用メモ:

KiCadで基板のガーバーを出力する際のオプション設定画面はこれ:

英語モードだとこう

この中で、「シルクをレジストで抜く(Subtract soldermask from silkscreen)」と「シルクからパッドを除外(Exclude pads from silkscreen)」は似ているようでやっている事も目的も違う。このオプションで影響を受けるのはどちらもシルクレイヤーのみ。

「シルクをレジストで抜く」のは基板上の露出した銅箔の上にシルク印刷が重ならないようにするためのもの。ファブの方でも対処してくれそうだけど通常チェックしておく。

「シルクからパッドを除外」は言葉からすると同じようにパッド(銅箔)部分にシルク印刷が重ならないようにするためのもののように思えるが、実はこれをチェックしない場合にシルク印刷に(元々は存在していない)パッドの形状を書き加えるもの。なお、書き加えたところで「シルクをレジストで抜く」がチェックされている場合は結局シルクが抜かれて印刷には出てこないので実質影響はない。

ではなんのためにこのオプションがあるかと言うと、シルクとパッド形状を一緒に紙に印刷する事で組み立て時のドキュメントにするために使う。ガーバーで出力する際には「シルクをレジストで抜く」と「シルクからパッドを除外」を一緒にチェックをはずす必要がある。が、ドキュメントにするためなのでガーバーではなくPDF等で出す方が良い (この場合はそもそも「シルクをレジストで抜く」オプション自体が存在しない)。

ついでに言うと、このパッドの形状をシルクに書き加える際の線の太さは「デフォルトの線幅(Default line width)」で決まる。この「デフォルトの線幅」は昔はあちこちで使われていたが、バージョンが上がって各部の線幅が個別に指定できるようになると共にあまり使われなくなっていてここ以外のどこで使われているかもう良くわからない。

こんな感じになる:

なお、KiCadの昔のバージョンではこのオプションは「Plot pads on silkscreen」であり、ロジックが逆、というか本来の目的に対しては直接的だった、がいつの間にかロジックがひっくり返った。そして更にこれを Python スクリプトから操作しようとすると API は "SetPlotPadsOnSilkLayer()" のままで名前も違えばロジックも逆というカオスな状況。

そして、この"SetPlotPadsOnSilkLayer()"は現行バージョンの実装にはあるのだが、なぜかドキュメントには一切出てこない。まあこの辺のちゃんとしたドキュメントはそもそも無い。今後APIごと削除される可能性が無いとも言えないので使って良いのかどうか迷うところ。

ちなみに「境界線とタイトルブロックをプロット(Plot border and title block)」というオプションもガーバーに出しても何の意味もないが、ドキュメント用として体裁を整えるのが目的になる。

Posted by g200kg : 5:00 AM : PermaLink

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

2021 NAMM 「Believe In Music」

来年1月の NAMM ショーは COVID-19 の影響でオンラインイベント「Believe In Music」に変更されたみたいですね。2021年夏、2022年冬の NAMM ショーの案内も出ているので今回だけの特別措置だと思いますが、オンラインでこういうイベントがあるのは気軽に見れて良いかも知れないな。

https://www.namm.org/support/believe-in-music-week

Posted by g200kg : 2:40 AM : PermaLink

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

zoom-ms-utility スタンドアローン版

タイミングを逸して今更感はあるのだけど ZOOM マルチストンプ用のパッチ編集アプリを Web アプリからスタンドアローンアプリ化したものを公開しました。と言っても NW.JS に突っ込んだだけなんですが。何年か前にもやろうとしたけど、当時はまだ NW.JS に多少問題があってできなかったのをそのまま放置してしまっていました。

実行形式をZIPで固めてありますが、Mac版については GateKeeper がありますので、$ spctl コマンドで自分で一時的に止めるなどの作業が必要になります。Catalina でも起動できるのは確認していますが、今後どうなるんですかね。

https://github.com/g200kg/zoom-ms-utility

Posted by g200kg : 5:57 PM : PermaLink

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

MIDI2.0とVST3.7

最近 MIDI 2.0 周辺の状況がそろそろ気になり始めたので色々と様子をうかがったりしています。先月末には VST SDK が 3.7 にアップデートされたのですが、その中にも MIDI 2.0 への言及が少しだけ追加されています。

https://www.steinberg.net/en/newsandevents/news/newsdetail/article/new-vst-37-sdk-available-5605.html

追加されたのはドキュメントだけで実装はもう前の版からやっているよ、という事みたいですが ( いや、やってるのかな? どこまでやってるのかは知らないけど)。

まず双方向通信で機器間のネゴシエーションをする MIDI 2.0-CI (Capability Inquiry) とか、プロファイルによるオートコンフィグレーション、プロパティ交換などは基本的にホストアプリの責任なのでプラグインがどうこうするという事は無いというスタンスで良いんですかね。

ホストアプリとプラグインの間の VST 規格として関係してくるのはプロトコルまわり、つまり MIDI 2.0 になって、ベロシティやコントローラー(コントロールチェンジ)の解像度の向上やパーノートコントローラーというあたりが追加されたのですが、これらが VST ではどう扱われるか、になってきます。

VST ではホストアプリとプラグインの間はノートオン、ノートオフ等の MIDI イベントの他、コントロールチェンジ的な各種パラメータは Parameter での受け渡しで密に繋がっていて、また音符毎に付与できるパーノートコントローラーに相当するものとして VST 3.5 で導入された NoteExpression があります。また、ベロシティやポリプレッシャーについては VST3 でのプラグインへの受け渡しは 32bit float なので、MIDI2.0で16bit/32bit int になってもまだ戦える、という事です。

いずれにしても、これらの MIDI 2.0 経由で入ってくる情報を VST のパラメータ等にどうマッピングして行くのかはホストアプリの責任、という事になります。プラグインとしては入ってくるパラメータを変に切り捨てたりせずに素直に使っていれば MIDI 2.0 の高解像なコントローラー等が使えるという事になりますね。

MIDI 1.0 => MIDI 2.0 => VST 3 の対応

Posted by g200kg : 12:42 PM : PermaLink

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

USB-IFがMIDIデバイスv2.0向けUSBデバイス・クラス仕様を公開

気が付いてなかったのだけど、先月こういうニュースがあったのだね。
USB-IFがMIDIデバイスv2.0向けUSBデバイス・クラス仕様を公開

usb.org のプレスリリースはこちら:
USB-IF Publishes USB Device Class Specification for MIDI Devices v2.0

MIDI1.0から2.0への変化はかなり大がかりなものなので、普及も簡単ではないだろうなとも思うのだけど、既に色々と動きはあるようですね。
とは言え...、

本格的に使われるには DAW の対応が必要だしそれには OS レベルで API が整備されていないといけないのだけど、この辺の動きはどうなんだろね。 iOS では coreMIDI が既に MIDI 2.0 に対応しているとかいう話もちらっと聞いたりしたけどそれは MIDI 1.0 へのフォールバックの話のような気がするし、Windows 系だと MIDI 系の API って今どうなってるっけ? ユニバーサル Windows プラットフォームでの API だと今は完全に MIDI 1.0 の切り口なのでこの辺に増設する事になりそう(大変そう)。

現行 MIDI 1.0 の仕様も長い時間の中で色々と不満が出てきていて、各社勝手に色々と拡張を試みたりし始めていたので、ばらばらになる前に統一規格にしようという動きは良いんじゃないですかね。まあ予想外に根本的な所からの刷新ではありましたが。

ここに至るまでに出てきていた色々...。

ROLI MPE 規格 : ROLI 5次元キーボード対応で1つのノートに複数チャンネルを使う奴。設定に使うのは RPN 6
Hi-Res Velocity Prefix : ピアノでベロシティの解像度が足りなくなったのでノートオンの前に付けるタイプ、 CC#88 (58H)
eXtended Precision MIDI : ヤマハ製のピアノのベロシティ拡張 CC#16 (10H)

Posted by g200kg : 5:07 PM : PermaLink

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

MIDI (SMF) ファイルのレガシーなノウハウとか今後とか

どこかにこういうものはあるだろうと思っていたのに意外と見当たらなくて、いきなり MIDI-dump ユーティリティなんか作ったりしましたけど、SMFの扱いはそれなりに癖があるのでメモ。

https://github.com/g200kg/midi-dump

ちゃんとした規格は AMEI のページから見れます。
http://amei.or.jp/midistandardcommittee/MIDIspcj.html

すっかりレガシーなノウハウになってしまいましたが、これから初めて SMF を触ろうとしているなら、はまりやすいのはこんな所です:

NoteOn のベロシティ 0 は NoteOff として扱う事。これと次のランニングステータスとの合わせ技でファイルサイズが小さくなる。
( 場合によっては処理が面倒な事になったりするのだが ) ランニングステータスをちゃんと処理するのを忘れないように。最近はデータサイズにあまり敏感では無くなったので忘れられがち。
チャンクの構造はビッグエンディアンだけどベンドデータなんかはリトルエンディアンなので混同しないように。
Track Name 等のテキスト系メタイベントのエンコーディングは基本無法地帯。日本で作られたMIDIファイルは s-jis 文字列が入っている事が多い。内容から自動認識するしかないが、CP1252 (ISO-8859-1) と S-JIS が混ざったりすると割とお手上げ。
読み込みの際に知らないタイプのチャンクはちゃんと読み飛ばす、チャンクのサイズはチャンクのlengthをリスペクトする事。XFフォーマットとか一部のMIDIファイルには追加のチャンクタイプが存在する場合がある。
データの読み込みでメタイベント End of Track にエンカウントしたら以降のデータは無視する事。各トラックのデータは EOT の後ろにゴミデータが存在する場合がある。

と、ここまでは復習。

ここからは予習。

既に MIDI 2.0 規格が発表されているわけで、今後 MIDI ファイルも 2.0 対応になっていくはずですが、MIDI 2.0 での MIDI ファイルがどうなるかはまだ不明です。MIDI 2.0 は双方向通信でネゴシエーションするのが大きな特徴なのだけど、MIDIファイルは基本的に楽曲再生用シーケンスデータとして使われるという事を考えると、ネゴシエーションは実機での接続に任せて MIDI ファイルはネゴシエーション後にシーケンサーに読み込むためのデータという事になるのかなあ。知らんけど。

MIDI 1.0 に対する下位互換はありますが、MIDI 2.0 で拡張された分解能の向上なんかが使えないと意味がないので、本命はやはり MIDI 2.0 ネイティブの UMP をファイル化する方法ですかね。つまり今までバイトストリーム状態でランニングステータスなんかを使って割とせこせことサイズ削減していたのが、Uint32 ベースのパケットストリームを扱う感じでしょうか。1楽曲あたりのサイズは増えそうだけどそこは時代の流れですね。

UMP のパケットストリームに適当なデルタタイムが付いている感じだとして MIDI 2.0 で追加された JR タイムスタンプ (Jitter Reduction) との関係はどうなるのか?

とか、まだ色々面倒な事がありそうですが、そのうち仕様が出てくるのではないかと期待。
まあテキスト系メタデータにエンコーディング指定が付いててくれればそれだけで...

MIDI 2.0 の規格はまだ英語版ですが AMEI のページからダウンロードできます。

http://amei.or.jp/midistandardcommittee/MIDI2.0/MIDIspcj2.html

結構大きな仕様なので、どこから読めば良いのか戸惑い勝ちだけど、100から104に順番に行くのが正攻法ですかね。ただ CI の周辺は今までにまったくなかった概念なのでなんとなくもやっとして全体像がつかみにくいので MIDI 2.0 プロトコルの UMP のあたりの話の方がとっつきやすいかも知れません。

何にしても MIDI 2.0 の規格は MIDI 1.0 の知識がある事を前提として書かれているので、MIDI 1.0 の内容を知らずにこれだけ読んでも多分なんだかよくわからなくなります。

Posted by g200kg : 12:38 PM : PermaLink

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

midi-dump : midi (SMF) ファイルを読みやすくダンプするユーティリティ

今更だし、大したものではないのだけど、ちょっと MIDI ファイルの中身を確認したい事があったので作った。
取り合えずのものなので、適当な所が残っている。

こういうちょっとしたツールのようなものはもう大体 Web アプリで良いかなと思っている。

GitHub Repository : midi-dump
"midi-dump" Utility

Posted by g200kg : 1:32 PM : PermaLink

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

Appleがハードウェア寄りなAPIの実装を拒否している件

Web MIDI、Web Bluetooth、Web USB、Web Serial...

と近年ハード寄りなブラウザ API がどんどん出てきていて、そこそこのものなら(ハードウェアの能力を限界まで絞り出すようなネイティブアプリがある以上完全に、とは言わないけど) Web アプリで済む世界は近いと思ってはいるのだけど、その一方でこういう話もあるのだよね。

元記事は6月末の頃のもののようだ。

厳しいなあ。
Gigazine : 「Appleが「プライバシー上の懸念あり」としてSafariへの一部ウェブAPIの実装を拒否」

面白そうな API が軒並み実装拒否対象になっている。まあ Web USB なんかが出てきた時に Web アプリからそんな所を触って大丈夫なのか? と多少は思ったというのも確かにあるけどね。Web MIDI は許して欲しいな、勝手な希望なのは承知しているけど。

対象の Web API は以下の通り :

・Web Bluetooth
・Web MIDI API
・Magnetometer API
・Web NFC
・Navigator API: deviceMemory
・NetworkInformation API
・Battery Status API
・Web Bluetooth Scanning
・AmbientLightSensor API
・EME Extension: HDCP Policy Check
・Proximity API
・WebHID API
・Serial API
・WebUSB
・Idle Detection

Posted by g200kg : 11:13 AM : PermaLink

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

ノブのラベルはどう配置するべきか

特に気にしていない人には本当にどうでも良い話だとは思うのだけど、GUI画面のツマミの周辺の配置をどうするべきかちよっと迷ったりする事が多いんですよね。つまり、下の図のラベルとリードアウトをノブに対してどこに配置するかという話です。

幾つか考えるべき点はあって、まず実際のハードウェア機器ではリードアウトは普通存在しないので、ノブとラベルの位置関係だけになります。これがどうなるかというと、世の中の趨勢としても個人的な嗜好としても、家庭用オーディオやラックマウント機器のようなものならラベルはノブの上、小型のガジェットや鍵盤付きシンセのような平置きして使うものなら下、かなあ。絶対ではなくてあくまで傾向ですけどね。

というのも実際のハードウェア機器だと視線の問題があって機器の形によって見下ろす視線で使うものと見上げる視線で使うものでノブの陰にならないようにしないと使いづらいという事情があります。

ソフトウェアGUIになるとどこに置いても陰にはならないのでこういう呪縛がなくなるわけですが、ハードウェア機器へのリスペクトの高さによって、傾向としては残るんでしょうね。ハードウェアエミュレート系のソフトウェアならなおさらです。

そして現在のパラメータを表示するリードアウトですが、エミュレーション系ならそんなもの付いてないのが当たり前なんですが、せっかくのソフトウェアのメリットでもあるので個人的には付けたくはなりますね。

という事で身の回りの音楽系プラグイン等を数十程度ざっと見てみたのですが、まずラベルがノブの上に来るのか下に来るのかという事で言えば、下派がやや優勢で、上40%、下60%程度かと思います。やはり家庭用オーディオ機器よりもシンセやストンプエフェクターなんかの方が近い存在なんですかね。

そしてやや意外だったのが、リードアウト付きの比率が結構低いようです。リードアウト付きは全体の20%～30%程度でしょうか。付けても機能的にマイナスになる事は基本的に無いと思いますが、これはやはり楽器系ソフトウェア特有のハードウェアリスペクトの高さによるものなのでしょうか。

それで全体の2～3割の選択として、リードアウトを付けるとすると、ラベルとの配置の兼ね合いが割と厳しくなります。上か下ははともかく、ラベルとリードアウトを同じ方向に付けると下の図のようになるわけですが、やっぱりちょっとごちゃごちゃした感じになってしまいます。実際こういうパターンのもそれなりに存在するし駄目ではないんですが。

という事で結局ラベルとリードアウトをそれぞれノブの上と下に振り分けるというパターンが無難な感じにはなるんですが、それで上下にどう振り分けるかとなると、どっちを重視するかみたいな話で、どうするのが良いかもうわからない。ただ個人的にはラベルを上、リードアウトを下という方向でなんとなく収束しつつある気はしています。

大して変わらんと言えば変わらんのだけど、ただ、1画面内でラベルが上にあったり下にあったり混在しているのは流石に避けるべきかなとは思います。

Posted by g200kg : 2:31 AM : PermaLink

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

webaudio-controlsのフロントページを作りました

今まで GitHub にそのまま置いていただけなのですが、ちょっとそれらしい形にしました。

そしてアプリケーションノート的なドキュメントも書こうとして色々と実装が不完全な所が露呈して結構本体にも手を入れる事に。@atsushieno さんのKnobのサイズの件とかも。まだ完全に理想通りではないかもだけど。

ついでに npm パッケージ (g200kg/webaudio-controls) にしてあります。なお npmjs ではなくて GitHub Packages なので npmjs しか使っていない人は少しだけ npm の設定が必要になります。

https://g200kg.github.io/webaudio-controls/docs/index.html

Posted by g200kg : 2:03 PM : PermaLink

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

ADSR がチョットワカルようになる記事

これまでに 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

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

g200kg

最近の記事

関連記事

シンボル

フットプリント

3Dモデル

使用法