« 2020年07月 | 2020年08月のアーカイブ | 2020年09月 »
2020/08/28
[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
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
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
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
MIDI2.0とVST3.7
最近 MIDI 2.0 周辺の状況がそろそろ気になり始めたので色々と様子をうかがったりしています。先月末には VST SDK が 3.7 にアップデートされたのですが、その中にも MIDI 2.0 への言及が少しだけ追加されています。
追加されたのはドキュメントだけで実装はもう前の版からやっているよ、という事みたいですが ( いや、やってるのかな? どこまでやってるのかは知らないけど)。
まず双方向通信で機器間のネゴシエーションをする 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
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
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
midi-dump : midi (SMF) ファイルを読みやすくダンプするユーティリティ
今更だし、大したものではないのだけど、ちょっと MIDI ファイルの中身を確認したい事があったので作った。
取り合えずのものなので、適当な所が残っている。
こういうちょっとしたツールのようなものはもう大体 Web アプリで良いかなと思っている。
GitHub Repository : midi-dump
"midi-dump" Utility
posted by g200kg : 1:32 PM : PermaLink
« 2020年07月 | 2020年08月のアーカイブ | 2020年09月 »
-->
g200kg