Products : ユーロラックモジュラー「RedLine」販売中
2018/10/23 (2018年10月 のアーカイブ)
楽器フェアが開催されました
先週の10月19日(金)～21日(日)の3日間、東京ビッグサイトで楽器フェア2018が開催されました。いつもは見に行くだけなんですが、今年はシンセフェスタの TFoM ブース内に出展してきました。しかしまあ、3日間は結構つらいな。
Posted by g200kg : 8:05 PM : PermaLink
2018/10/16 (2018年10月 のアーカイブ)
ABC2018A in KAWASAKI
先週の土曜日の話になってしまいますが、2018年10月13日、川崎市産業振興会館で ABC 2018A (Android Bazaar and Conference 2018 Autumn) が開催され、展示の方に一応 Web Music Developers JP 名義でブースを出してきました。
と言っても、照明をびかびかに光らせて音関係は恒例の缶叩き機が鳴るという内容で、大半の時間は説明する人も不在という暴挙により、良くわからない展示になっていましたけど。そもそも Android とはほとんど関係がない代物だしね。
展示全体としては、開催地が川崎というやや微妙な感じもあって人は少なめではないですかね。コンファレンスと同時開催なのでコンファレンス中は人が来ないというのもありますが、見に来る人も常連的でかなり内輪な感じになってしまっているかも知れません。
Android を取り巻く環境として Android Things だの Kotlin だのという新しめのものはあるのだけど Android 全体の雰囲気がもう枯れた技術的なものになっていて、バージョンが上がる度にお祭り的な雰囲気があった初期の頃とはだいぶ違ってきている気もします。今後 Android 関係はどうなって行くんでしょうか。枯れた技術で安定して使えるという意味では悪い事でもないのかも知れませんが。
あまり写真を撮っていないのだけど取り合えず目についたものとか...:
Posted by g200kg : 2:39 AM : PermaLink
2018/10/03 (2018年10月 のアーカイブ)
WebAudioAPI CR 日本語訳公開
Web Audio API の日本語訳を 2018年9月18日の CR (Candidate Recommendation) 版に更新しました。
6月の WD からそれほど大きくは変わっていないので、大雑把にペタペタとコピペして簡単に作れるかと思ったのだけど、そう甘くはないようだ。文章が微妙に変わったりしているので、やっぱりちゃんとチェックしながらじゃないと作れない。
6月のワーキングドラフト以降の変更点は 変更履歴 - 2018年6月19日ワーキングドラフト以降 のあたりを見てください。
https://g200kg.github.io/web-audio-api-ja/
Posted by g200kg : 12:40 PM : PermaLink
2018/09/30 (2018年09月 のアーカイブ)
KiCad : Pythonスクリプトでガーバーをまとめる
今年 7 月に基板 CAD の KiCAD が 1 年ぶりくらいに 5.0 にバージョンアップして以来、はじめてちゃんと使ってみたのですが、なかなか良いです。レンダリングを OpenGL にすると動かない機能があるとかいう中途半端な感じがなくなってるし、ライブラリもかなり整備されました。個人的にはワイヤーを削除した時にジャンクションだけが取り残されたりしなくなったのでフラストレーションが激減しました。
KiCad
それでもうひとつ気になる機能があって Action Plugins という奴なんですが、これは Python で書いたプラグインでメニューからマクロ操作的な事ができるというもので 5.0 から使える予定だったのですが、これの動かし方がわからない。
という事で色々調べた結果、今公開されている 5.0.0 では何かの手違いで無効にしたまま公開してしまったようです。そのうちアップデートされると思いますが、今すぐ使ってみるには安定版の 5.0.0 ではなくて Nightly Build の方を入れれば試せます。
以前のバージョンでも Python スクリプト自体は使えたのですが、呼び出し方にいまいち問題があって、Python コンソールを開いてコマンド名を打ち込む必要がありました。これだと、ちょっとした便利コマンドみたいなものをせっかく作っても、いざ使おうとした時にはもう使い方を覚えていないとか、存在そのものを覚えていないという事になりがちです。 で、これをメニューに登録できるようにした、とまあそれだけの事ではあるんですけど、使い勝手はかなり違うと思います。
ただこの Python スクリプト周りはまだドキュメンテーションが行き届いていないので、どうやればやりたい事ができるのか調べるのには結構手探りの試行錯誤が必要そうです。とりあえず、ガーバーファイルを FusionPCB とか Elecrow スタイルにリネームして ZIP にまとめるスクリプトを書いてみました。
動かすには Linux の場合、http://docs.kicad-pcb.org/doxygen/md_Documentation_development_pcbnew-plugins.html にあるように、このファイル ( action_menu_gerber_zip.py ) を /usr/share/kicad/scripting/plugins/ あたりに置けば動くようです。ただし Windows の場合はこの説明が怪しくて色々やった所どうやら、
C:\Users\ユーザー名\AppData\Roaming\kicad\scripting
に置けば動作するようです(このあたりの挙動はまだ確定かどうかわからない)。スクリプトの中身ですが、FusionPCB や Elecrow を使っている人なら何度もやる事になるガーバーをリネームしてZIPで固めるという作業を自動的に行います。出力はプロジェクトのあるフォルダ下に 'Gerber' というサブフォルダを作成してそこに納めます。
FusionPCB と Elecrow は必要とするファイルの拡張子は同じなのですが推奨する条件が多少違っているので、一応切り替えやすいように先頭の方にまとめています。ダイアログを出して設定したりできるようにするべきかも知れませんが、まあそのうち KiCad 安定版で動作するようになったら...
| 設定 | 説明 | FusionPCB | Elecrow |
|---|---|---|---|
| merge_npth | ドリルファイルのメッキなしとありを1ファイルにまとめるか | まとめるのが推奨 (多分別ファイル xxx-NPTH.TXT を添付でもやってくれるとは思う) | 別ファイル推奨。まとめた時はメッキありになっちゃうかも |
| use_aux_origin | 補助座標 AuxOrigin を使うかどうか | どちらかと言うと KiCad 側のドリルファイルの補助座標を Python から扱うやり方が正しいかどうか多少曖昧な所があるけど多分どちらでも大丈夫 | |
| excellon_format | ドリルファイルの数値のフォーマット | サプレスリーディング推奨 | 推奨は不明だけど、DECIMAL_FORMAT で発注している人が多そう |
動作は Windows 10 + KiCad (6.0.0-rc1-dev-536-g40a3b4a53) 環境でしか確認していません。
# file : action_menu_gerber_zip.py
#
# (gerber_zip)
#
# Copyright (C) 2018 g200kg
# Released under MIT License
#
import pcbnew
from pcbnew import *
import wx
import os
import zipfile
#
# Setup params
#
gerber_subdir = "Gerber"
merge_npth = False
use_aux_origin = True
excellon_format = EXCELLON_WRITER.DECIMAL_FORMAT
#excellon_format = EXCELLON_WRITER.SUPPRESS_LEADING
#
#
#
class GerberZip( pcbnew.ActionPlugin ):
'''
Make Gerber Zip-file for Elecrow / FusionPCB
'''
layers = [
[ F_Cu, 'GTL', None ],
[ B_Cu, 'GBL', None ],
[ F_SilkS, 'GTO', None ],
[ B_SilkS, 'GBO', None ],
[ F_Mask, 'GTS', None ],
[ B_Mask, 'GBS', None ],
[ Edge_Cuts,'GML', None ],
[ In1_Cu, 'GL2', None ],
[ In2_Cu, 'GL3', None ],
[ In3_Cu, 'GL4', None ],
[ In4_Cu, 'GL5', None ],
]
max_layer = 7
def defaults( self ):
self.name = "Make Gerber-Zip (Elecrow/FusionPCB style)"
self.category = "Plot"
self.description = "Make Gerber-Zip-file for Elecrow / FusionPCB"
def forcedel( self, fname ):
if os.path.exists(fname):
os.remove(fname)
def forceren( self, src, dst ):
self.forcedel(dst)
os.rename(src, dst)
def Run( self ):
board = pcbnew.GetBoard()
board_fname = board.GetFileName()
board_dir = os.path.dirname(board_fname)
board_basename = (os.path.splitext(os.path.basename(board_fname)))[0]
gerber_dir = '%s/%s' % (board_dir, gerber_subdir)
drill_fname = '%s/%s.TXT' % (gerber_dir, board_basename)
npth_fname = '%s/%s-NPTH.TXT' % (gerber_dir, board_basename)
zip_fname = '%s/%s.zip' % (gerber_dir, board_basename)
if not os.path.exists(gerber_dir):
os.mkdir(gerber_dir)
max_layer = board.GetCopperLayerCount() + 5
# PLOT
pc = pcbnew.PLOT_CONTROLLER(board)
po = pc.GetPlotOptions()
po.SetOutputDirectory(gerber_dir)
po.SetPlotValue(True)
po.SetPlotReference(True)
po.SetExcludeEdgeLayer(False)
po.SetLineWidth(FromMM(0.1))
po.SetSubtractMaskFromSilk(True)
po.SetUseAuxOrigin(use_aux_origin)
for layer in self.layers:
targetname = '%s/%s.%s' % (gerber_dir, board_basename, layer[1])
self.forcedel(targetname)
self.forcedel(drill_fname)
self.forcedel(npth_fname)
self.forcedel(zip_fname)
for i in range(max_layer):
layer = self.layers[i]
pc.SetLayer(layer[0])
pc.OpenPlotfile(layer[1],PLOT_FORMAT_GERBER,layer[1])
pc.PlotLayer()
layer[2] = pc.GetPlotFileName()
pc.ClosePlot()
for i in range(max_layer):
layer = self.layers[i]
targetname = '%s/%s.%s' % (gerber_dir, board_basename, layer[1])
self.forceren(layer[2],targetname)
# DRILL
ew = EXCELLON_WRITER(board)
ew.SetFormat(True, excellon_format, 3, 3)
offset = wxPoint(0,0)
if(use_aux_origin):
offset = board.GetAuxOrigin()
ew.SetOptions(False, False, offset, merge_npth)
ew.CreateDrillandMapFilesSet(gerber_dir,True,False)
if merge_npth:
self.forceren('%s/%s.drl' % (gerber_dir, board_basename), drill_fname)
else:
self.forceren('%s/%s-PTH.drl' % (gerber_dir, board_basename), drill_fname)
self.forceren('%s/%s-NPTH.drl' % (gerber_dir, board_basename), npth_fname)
# ZIP
with zipfile.ZipFile(zip_fname,'w') as f:
for i in range(max_layer):
layer = self.layers[i]
targetname = '%s/%s.%s' % (gerber_dir, board_basename, layer[1])
f.write(targetname, os.path.basename(targetname))
f.write(drill_fname, os.path.basename(drill_fname))
if not merge_npth:
f.write(npth_fname, os.path.basename(npth_fname))
wx.MessageBox('GerberZip Complete.\n\n%s' % zip_fname, 'Gerber Zip', wx.OK|wx.ICON_INFORMATION)
GerberZip().register()
Posted by g200kg : 1:45 PM : PermaLink
2018/09/19 (2018年09月 のアーカイブ)
Web Audio API が CR になりました
ついこの間 6月版の WebAudio API WD の日本語訳を作ったばかりなんですが、9月18日付けで CR が公開されました。WD の更新は結構ゆっくりだったのに急に動きが速まったんでしょうか?
https://www.w3.org/TR/2018/CR-webaudio-20180918/
W3C 勧告のプロセスとしては、次のような手順を踏みます。
- WD ( Working Draft ) : ワーキンググループが作成する草案
- CR ( Candidate Recommendation ) : WD の内容が固まったら勧告候補となり、この後も、レビューやら仕様に従った実装やらが進められる
- PR ( Proposed Recommendation ) : 勧告候補に沿った実装が(できれば二つ以上)存在するなどの条件を満たしたら、勧告案として最終レビューが行なわれる
- Recommendation : 勧告案のレビューをパスする事で最終的にこの「W3C勧告」となる
という事で、日本語訳の方もまた何とかしないといけないと思っているのですが、ざっと見た感じでは、6月版 WD から機能的に増えたものがあるわけではなくて説明がおかしかった所を修正したり、動作が不明瞭だった部分を加筆したりという内容になっています。基本的な内容については 6月版 WD と違いはありません。
CR での具体的な変更点は ChangeLog の Since Working Draft of 19 June 2018 で確認できます。
CR の日本語訳はそのうちまたこちらで公開するつもりです。 Web Audio API (日本語訳)
Posted by g200kg : 3:26 PM : PermaLink
2018/09/18 (2018年09月 のアーカイブ)
整数の平方根(切り捨て)
FPU を使えない環境でたま～に使いたくなって、どうやってたっけ? と毎回昔のコードを掘り返したりしているので、メモ。
バビロニアンメソッドと呼ばれる奴で、16bit値くらいなら割り算10回分程度。
真の値は戻り値と戻り値 +1 の間になるように多少気を使っている。
unsigned int sqrint(unsigned int x){
unsigned int y1 = x, y2 = (x + 1) >> 1;
while(y2 < y1)
y1 = y2, y2 = (y1 + x / y1) >> 1;
return y1;
}
9.21 追記-----
これだと初期値が適当すぎて収束が遅いので、@xevixeviさんが、もうちょっと改善する案をツイートしてくれましたので、追記しておきます。
有効ビット数まで切り詰めて初期値とするので必要な反復計算がかなり減ります。速度重視ならこっち。また最初の例だと、UINT_MAX を入力した時に例外が起こるのを回避できてます。
unsigned int sqrint(unsigned int x){
unsigned int y1 = x, y2 = 1, x2 = x;
while(x2 >>= 2)
y2 = (y2 << 1) + 1;
while(y2 < y1)
y1 = y2, y2 = (y1 + x / y1) >> 1;
return y1;
}
ついでに...
処理時間に占める除算の割合が高そうなので、ループの終了条件の確認で1回余計に回るのを避けるために毎回乗算するパターン。これが割に合うかどうかは CPU 次第だけど、除算に比べて乗算が充分に速ければこっちの方が速くなる可能性があります。
unsigned int sqrint(unsigned int x){
unsigned int y = 1, x2 = x;
while(x2 >>= 2)
y = (y << 1) + 1;
while(y * y > x)
y = (y + x / y) >> 1;
return y;
}
Posted by g200kg : 12:20 PM : PermaLink
2018/09/02 (2018年09月 のアーカイブ)
WebAudio API 2018 日本語訳 最新版公開
6月19日に公開されていた W3C の「Web Audio API」のワーキングドラフトの日本語化が完了したので公開します。前回の版(2015年版) と比べて大きな所では
・ScriptProcessor の置き換えとなる AudioWorklet の仕様
・名前が何度かふらふら変わっていた Panner 関係の整理
・新しいノード constantSourceNode、mediaStreamTrackSourceNode の定義
・ノードのコンストラクタの仕様
あたりが最新仕様に沿ったものになっています。
なかなか翻訳に手こずったなと思ったら、ブラウザを作る人向けの内部アルゴリズムの手順等も大幅に加筆されているので2015年版に比べてサイズが 3 倍近くになってます。
Web Audio API を軽く触ってみたいという時には少し重いドキュメントですが、これが原典ですし、ソフトウェアによる音響処理の実装の解説として見れば、実際的な音響処理について大勢が寄ってたかって編集/レビューしたとてもレアな文書だと思います。興味がある人には読み物としてじっくり読んでもとても有用な内容です。これが普通に公開されているのだから読まないともったいないですよ。
Web Audio API, W3C Working Draft, 19 June 2018 (日本語訳)
Posted by g200kg : 11:32 AM : PermaLink
2018/08/29 (2018年08月 のアーカイブ)
MIDIのTRS接続規格化
1週間ほど前、MIDI 信号を TRS (いわゆる三極プラグ)フォンジャックでの接続が規格化されたというニュースが Twitter 等で流れていたのですが、ちょっと状況を整理しておきたいと思います。
元々の規格では MIDI は DIN の丸形 5 ピンで接続するという事になっていたのですが、機器の小型化が進み、さすがに今となってはコネクタが大きすぎて支障があるという事が背景にあります。ですが、一方で最近の MIDI キーボード等の MIDI 機器は USB 接続のものがほとんどで生の MIDI 信号を扱う機会が少なくなっていたので問題が表面化していなかった、とも言えます。
流れが変わったのは 2010年頃以降、iOS デバイス用の MIDI インターフェースなんかが出始めた頃だと思います。DIN コネクタが大きすぎるのでインターフェースとしては ミニジャック経由の専用ケーブル(ブレークアウトケーブル)を同梱していた訳です。
それでまあ、そういう TRS 経由 MIDI 機器が各社からちらほらと出てきて、基本的にはその機器それぞれが専用のケーブルを同梱するという形ではあったのですが、似たような見た目なのに結線が各社ばらばらで 2.5mm だったり 3.5mm だったりになってしまったので、これはまずかろうという事で規格化されたという経緯ですね。
結果として規格化された結線は次の通りです:
| TRS | DIN 5pin | |
|---|---|---|
| Sink | Tip | Pin 5 |
| Source | Ring | Pin 4 |
| Shield | Sleeve | Pin 2 |
なおサイズについては、2.5mm / 3.5mm どちらも否定はしていませんが 2.5mm 、いわゆるミニミニジャックが推奨となっています。
正式な規格は MMA のサイトでメンバー登録すればダウンロードできます。
https://www.midi.org/articles-old/trs-specification-adopted-and-released
また同じく MMA のこちらのページでは、結線を 「TRS MIDI A」と「TRS MIDI B」に分けて、現在ある各社の機器がどちらの結線になっているかが書かれています。「TRS MIDI A」が今回規格になった方です。
https://www.midi.org/articles-old/updated-how-to-make-your-own-3-5mm-mini-stereo-trs-to-midi-5-pin-din-cables
これによると、規格化された結線に一致しているのは、
■ Line 6 / littleBits / Korg / MakeNoise / IK Multimedia / inMusic(Akai)
です。IK Multimedia が最近出した UnoSynth もこれに沿っているようです。
逆に、
■ Arturia / Novation / 1010Music
は結線が逆になってしまった、という事ですね。
またサイズは IK Multimedia や Line 6 などの iOS デバイス向けは 2.5mm が多いですが、Korg SQ-1 なんかは 3.5mm ですので、ミニ⇔ミニミニ変換なんかが必要になります。
なお、Arturia の旧製品、BeatStep (無印、Proじゃないもの) は、TS(二極)ジャックでまた結線が違うようです。線が 2 本しかないので Tip に Source 側に信号を載せたものが出ているような感じです。
という事で現在市場に出回っている 2.5mm または 3.5mm のジャックで MIDI を接続する機器はまだこの規格に沿っていないものがかなり出回っています。
この規格ベースで何かを作りたいというような話なら、ケーブルは Line 6 か IK Multimedia(2.5mm)、Korg SQ-1用(3.5mm)、MakeNoise O-Coast用とかで売られているものを探す感じになります。モジュラー系のケーブルなら MakeNoise 用のケーブルが 5$ くらいで割合安く売られているようです。馴染みが無いと買いにくいかも知れませんが。逆結線の Arturia Beatstep用なんかも売られているようなので、間違えるとまずいですね。ケーブルの DIY 情報なんかを検索しても逆の結線のものも出てくるので、何を接続するためのものなのかは良く確認が必要です。
下の図が規格的に正しい結線のはずだけど、コネクタの male / female とかどっち側から見てるとかを勘違いして結局間違えるというのもありがちですが。
DIN の MIDI は 5ピンとは言ってもカレントループが 1 つだけなので、信号は シールドとソースとシンクの 3本だけです。TRS のスリーブはさすがにシールドに割り当てられるのが妥当なので、実質の結線としては 2 種類なのに、逆の結線にしてしまった製品がでてくるとはなんという協調性の無さ... と言ってもどちらの言い分もわかる気はするんですけどね。
カレントシンク側が信号のメインなんだからチップに割り当てるべきだろ、とか、カレントソース側はいつも電圧がかかってるのでリングに割り当てるのはなんかやだ、とか。
Posted by g200kg : 11:53 AM : PermaLink
...更に以前の記事...
g200kg