2019/03/22 (2019年03月 のアーカイブ)
「ヨンナナ」プラグについて
エレキギターなんかに繋ぐ 6.3mm のプラグの事、何て呼んでますか? 音声用のプラグとしては最近ではポータブル機器を中心に 3.5mm 径の「ミニプラグ」とか 2.5mm 径の「ミニミニプラグ」の方が見かける機会も多いですが、あれの大きい奴、直径 1/4インチ(6.3mm)の奴です。
おそらくですが「標準プラグ」という呼び方が一番一般的なのではないかと思いますが、「モノフォン」とか「2P(ツーピー)」とか言う人もいるかも知れません。そして他の呼び方として特に PA 関係では「ヨンナナ」という言い方が一部ではされています。
これはパッチベイなどで使われていた同じ6.3mm径の「110号(ヒャクトウ)」プラグとの取り違えを防ぐため「ヨンナナ」と呼んでいた、とここまではまあまあ知られた話ではあります。
という事で「偏ったDTM用語辞典」でも「"ヨンナナ"というのは標準プラグの事」というような説明を付けていたのですが、いやそうじゃないよ、っていう話があってその底なし沼のような歴史について@linear_pcm0153さんより知見を得たのでとりあえず修正しましたが、これは掘っていくと相当なカオスになっているようです。せっかくなのでもう少しだらだら書いてみます。
偏った DTM 用語辞典 : ヨンナナプラグ
何で「ヨンナナ」なのかという根拠として大きなものは古い JIS 規格、JIS C 6501 に定義されていた「47号プラグ」なのですが、ここで定義されたプラグというのが実は現在広く使われている「標準プラグ」とは少し違って、先端が傘のような形ではなく丸っこい球に近い形になっています。
今となっては滅多に見る事はないと思いますが、あーそう言えば昔、先端が丸いプラグがあったなあ...あれが本物の「ヨンナナ」プラグだったのか!! なんてちょっと感慨深いです。
この 47 号プラグの件については、@linear_pcm0153さんが相当深い所まで資料を発掘されていて、現在、1907年のウエスタン・エレクトリックのカタログに「No. 47 Plug」が載っている、という所まで行きついているようです。いやいや、100年以上前なのか!って凄い所まで繋がってますね。
この解説は間違いです。
— Holy Cater (@linear_pcm0153) 2019年3月21日
偏ったDTM用語辞典 - ヨンナナプラグ:47 Plug https://t.co/fpCbIrrKwR @g200kgさんから
なお「47号プラグ」を定めていた JIS C 6501 は1973年に既に廃止されており、現在の「標準プラグ」に相当するものは JIS C 6560 に定められてる「大型単頭プラグ」になりますが、この両者には特に継承関係等はありません。よく見るとこれだけ先端の形状が変わっているのだから同じプラグであるはずがないですね。
と言うか、47号プラグの丸い形状って今見ると引っ掛かる部分が少なくて凄く抜けやすそうです。それで抜けにくくするために今の形状に改良されたという事なのでしようか。
おそらく巷で使われている所ではまだまだ使われている「ヨンナナ」という言葉ですが、実際問題としては、「標準プラグ」を指して符丁的にそう呼んでいると思って間違いはないと思いますが、やっぱり私としては「標準プラグ」派かなあ。ただし 47 号プラグは 2 極 (TS) 限定なのに対し「標準プラグ」は 2 極 (TS)と 3極 (TRS) を含む名前なので 2 極限定だと標準TS とか? ちょっと悩む所ではあります。
Posted by g200kg : 10:46 PM : PermaLink
2019/03/05 (2019年03月 のアーカイブ)
Web×Iot メイカーズチャレンジ東京ハッカソンが開催されました。
先週末、3月2日(土)、3月3日(日) の2日間、Web × Iot メイカーズチャレンジ東京ハッカソンが開催され、メンターとして参加してきました。
このイベントは2017年から始まった総務省主催のイベントで、30才未満のエンジニアを対象に IoT システム開発の若手エンジニア育成を目的として札幌から沖縄まで全国9ヶ所で順次開催されています。私がメンターをやったのは東京で開催されたハッカソンですが、既にその1ヵ月程前に事前の講習会とアイデアワークショップが2日間行われており、一応チーム分けと作りたいものが決まった所からのスタートです。
制御系は Web 技術ベースで IoT システムを構築できる「CHIRIMEN for Raspberry Pi」が基本になっています。
ハッカソンの実質の作業時間は1日半程度ですので、この時間内に動くものを完成させるのは簡単ではありません。各チーム想定外のトラブルに遭遇しつつの開発になります。
プラットフォームとなるシングルボード PC にセンサーやアクチュエーターを組み合わせて様々なシステムを簡単に構築できるというのが IoT と呼ばれるものの目指す所ではあるのですが、それでも1日半程度の時間でちゃんとデモができるものを組み立てるには、どこを切り捨ててどういう風に作るかの見極めが大事ですね。
このハッカソンでは、かなり大き目のメカ的な造作を動かしたいという話が多めで、その辺の工作に苦労しているチームが多かったようです。ソフトウェア関係等では、発表時間が迫ってきた所で突然動かなくなる等、ありがちなトラブルも色々あったようですが、まあ、そういうものですよね。トラブルも良い経験なのではないでしょうか。実際、最優秀賞を取った寝落ち検出システムも発表時間が迫るほどに不具合が多発して最終的にはかなり人力に頼りつつのデモとなりました。
なお、今回を含め全国各地で開催されたハッカソンの最優秀作品は、3月8日(金)にベルサール神田で行われるスマートIoT推進フォーラム総会で展示されます。
Posted by g200kg : 11:49 PM : PermaLink
2019/02/13 (2019年02月 のアーカイブ)
webaudio-macronodes
これは GitHub に置いてあるリポジトリの説明です。
リポジトリ:webaudio-macronodes
Web Audio API のノードは全体的に機能の粒度が細かめで組み合わせの自由度は高いですが、反面何らかのエフェクターのようなものを構成するには複数のノードを組み合わせる必要があり、エフェクターの内部構造に関する知識を必要とします。
前回の記事で「[Web Audio API] 既存ノードを組み合わせたカスタムノードの作り方」というのを書いたのですが、これを使っていわゆるギターエフェクター的な機能を単一のノードにまとめる事ができます。
webaudio-macronodes は良くあるエフェクターのセットを Web Audio API のノードとして使えるようにまとめたものです。特長は、ノードの生成や接続、パラメータへのアクセスに関して、例えば GainNode や BiquadFilterNode のような通常の Web Audio API のノードとまったく同じ使い方ができる事です。
使い方
本体は webaudio-macronodes.js というファイルになるのでこれを読み込みます。GitHub pages から直接読み込むならば、次の行を HTML に追加します。<script src="https://g200kg.github.io/webaudio-macronodes/webaudio-macronodes.js"></script>ノードの生成
コンストラクタを使って生成します。audioContext.createGain() のようなファクトリメソッドはサポートしていません。 例えば、
toneControl = new Macro_ToneControlNode(audioContext);
toneControl = new Macro_ToneControlNode(audioContext, {bass:10, mid:0 treble:-3});
ノードの接続
通常のノードと同様に connect() メソッドで接続して行きます。このノードに対する接続が Web Audio API の通常のノードと同様に connect() メソッドを使う事でできるのが webaudio-macronodes の肝の部分です。例えば
sourceNode.connect(toneControl).connect(audioContext.destination);
パラメータへのアクセス
webaudio-macronodes の各ノードはそれぞれエフェクトのかかり方を調整するパラメータを持っています。これらのパラメータは基本的に AudioParam 型になっていますので、setValueAtTime() 等のオートメーション関数を使うなり、他のノードの信号を connect() するなり自由にアクセスできます。例えば
now = audioContext.currentTime;
toneControl.bass.setValueAtTime(0,now);
toneControl.bass.linearRampToValueAtTime(12,now+10);
エフェクトの一覧
パラメータが取る値の範囲等の詳細はリポジトリを見てください。リポジトリ : webaudio-macronodes
| エフェクト | パラメータ | 説明 |
|---|---|---|
| Macro_ToneControlNode | treble mid bass | 高音/中音/低音のトーンコントロール |
| Macro_GraphicEqNode | eq[] | 7 バンド・グラフィックイコライザー |
| Macro_ChorusNode | rate depth | 一般的なコーラスエフェクト |
| Macro_PhaserNode | rate depth | 一般的なフェイザーエフェクト |
| Macro_DeepPhaserNode | rate depth resonance | フィードバック付きのフェイザーエフェクト |
| Macro_DelayNode | delayTime feedback mix | 一般的なディレイエフェクト |
| Macro_PingPongDelayNode | delayTime feedback mix | 左右チャンネルから交互に出るディレイエフェクト |
| Macro_BitCrusherNode | bits | ビット深度を減少させるビットクラッシャーエフェクト |
| Macro_OverDriveNode | drive level | サチュレーションによる歪みを付加するオーバードライブエフェクト |
| Macro_FuzzNode | fuzz level | 倍音の強い歪みを付加するファズエフェクト |
| Macro_AutoWahNode | frequency Q sense | 音の大きさでフィルターを変化させるオートワウエフェクト |
Posted by g200kg : 8:50 AM : PermaLink
2019/02/01 (2019年02月 のアーカイブ)
[Web Audio API] 既存ノードを組み合わせたカスタムノードの作り方
少し前に GitHub にサンプルのリポジトリだけ置いてあったのですが、これは Web Audio API で幾つかのノードを組み合わせて独自のノードを作る方法の説明です。処理をすべてスクラッチから作るなら AudioWorkletNode を使えば良いのですが、単に既存のノードを組み合わせて1つのノードとして動作させるには少し裏技的な手法が必要になります。
GitHub : g200kg/webaudio-customnode
基本的に Web Audio API の各種ノードの機能はかなり細かく分けられていますので、一般的なエフェクターのようにまとまった機能のものを作るには幾つかのノードを組み合わせる必要があります。典型的な例がディレイエフェクトで、Web Audio API の DelayNode は信号を指定の時間遅らせるだけのものですから、エフェクター的ないわゆるディレイ効果を作るには、元音とのミックスや音を繰り返させるフィードバックの機能が欲しい所です。
上の図が今回作るサンプルのカスタムノード、MyDelayNode の構造です。入力端及び出力端は必ずしも GainNode でなくても良いのですが、単一の connect() メソッドでの接続ができるように信号が 1 本にまとまっている必要があります。
この MyDelayNode を標準の1つのノードと同等の方法で使えるようにします。つまり、
- var myNode = new MyNode(audiocontext, option) // コンストラクタでノードを作成できる。
- myNode.parameter.setValueAtTime(0,0) // 必要なパラメータにアクセスしオートメーションも使える。
- myNode.connect(otherNode) // ノードから出力を接続できる。
- otherNode.connect(myNode) // このノードに対して接続できる。
class MyDelayNode extends GainNode {
constructor(actx,opt){
super(actx);
// Internal Nodes
this._delay = new DelayNode(actx, {delayTime:0.5});
this._mix = new GainNode(actx, {gain:0.5});
this._feedback = new GainNode(actx, {gain:0.5});
this._output = new GainNode(actx, {gain:1.0});
// Export parameters
this.delayTime = this._delay.delayTime;
this.feedback = this._feedback.gain;
this.mix = this._mix.gain;
// Options setup
for(let k in opt){
switch(k){
case 'delayTime': this.delayTime.value = opt[k];
break;
case 'feedback': this.feedback.value = opt[k];
break;
case 'mix': this.mix.value = opt[k];
break;
}
}
this._inputConnect = this.connect; // input side, connect of super class
this.connect = this._outputConnect; // connect() method of output
this._inputConnect(this._delay).connect(this._mix).connect(this._output);
this._inputConnect(this._output);
this._delay.connect(this._feedback).connect(this._delay);
}
_outputConnect(to,output,input){
return this._output.connect(to,output,input);
}
}
- 1 行目、クラスは既存のノード、例えば GainNode の子クラスとして extends で派生させます。適当に作ったクラスでは他のノードからの接続ができません。この親クラスのノードが入力端のノードとなります。
- 24、25 行目、このカスタムノードからの出力となる connect() メソッドは子クラス側でオーバーライドすれば良いのですが、その前に元の connect() メソッドを確保しておきます。ここで確保した inputConnect で、入力端子である親クラスの GainNode に入ってくる信号を取り出す事ができます。
- 4 ～ 8 行目、内部で使用するノードです。
- 9 ～ 12 行目、カスタムノードとして必要なパラメータを外に引っ張り出します。
もう1つの例、ピンポンディレイです。これはディレイ音が左右のチャンネルから交互に出るエフェクトで、DelayNode を分割して途中からタップを出し、左右のチャンネルに振り分けています。
入出力の接続に関しては前のサンプルと同様ですが、ここで問題になるのは、2 つある DelayNode の delayTime パラメータをどうやって制御するかという点です。単一の AudioParam 型パラメータから 2 つの DeleyNode を連動して動かす必要があります。これには ConstantSourceNode が使えます。ConstantSourceNode の offset パラメータを外部に対して delayTime パラメータとして露出させ、内部では connect() メソッドによるノード間の接続で DelayNode の delayTime に接続します。
class MyPingPongDelayNode extends GainNode {
constructor(actx,opt){
super(actx);
// Internal Nodes
this._delay1 = new DelayNode(actx, {delayTime:0.5});
this._delay2 = new DelayNode(actx, {delayTime:0.5});
this._merger = new ChannelMergerNode(actx);
this._constant = new ConstantSourceNode(actx, {offset:0.5});
this._mix = new GainNode(actx, {gain:0.5});
this._feedback = new GainNode(actx, {gain:0.5});
this._output = new GainNode(actx, {gain:1.0});
// Export parameters
this.delayTime = this._constant.offset;
this.feedback = this._feedback.gain;
this.mix = this._mix.gain;
// Options setup
for(let k in opt){
switch(k){
case 'delayTime': this.delayTime.value = opt[k];
break;
case 'feedback': this.feedback.value = opt[k];
break;
case 'mix': this.mix.value = opt[k];
break;
}
}
this._inputConnect=this.connect; // input side, connect of super class
this.connect=this._outputConnect; // connect() method of output
this._inputConnect(this._delay1).connect(this._delay2).connect(this._merger,0,0).connect(this._mix).connect(this._output);
this._delay1.connect(this._merger,0,1);
this._inputConnect(this._output);
this._delay2.connect(this._feedback).connect(this._delay1);
this._constant.connect(this._delay1.delayTime);
this._constant.connect(this._delay2.delayTime);
this._constant.start();
}
_outputConnect(to, output, input){
return this._output.connect(to, output, input);
}
}
MyPingPongDelayNode サンプル
このような手法で class の登録さえすれば、標準のノードと同様の使い方が可能な、独自のノードが使えるようになります。あまり複雑な構造になりすぎるとパフォーマンスに影響が出てきそうではありますが、内部のノードの JavaScript の処理をノードの接続で置き換えるのがポイントになります。
なお、Web Audio API の V2 では、複数のノードを組み合わせたものを格納できるコンテナとなるノードの検討がされるようです。これが使えるようになれば、もっと自然な方法でこういう事ができるようになると思いますが、現在の仕様内でもやり方を工夫すれば同様の事ができますので、覚えておけば役に立つ事もあるかも知れません。
Posted by g200kg : 4:13 AM : PermaLink
2019/01/30 (2019年01月 のアーカイブ)
SkinMan 1.01
8 年くらい前にリリースしてそのままになっていたお絵描きプログラム「SkinMan」にバグレポートが来て、そもそも何をやってたか思い出せるかどうかが危ぶまれたのだが、何とか直ったようなので、今更だけどバージョンアップしておいた。
バグの内容はファイルを保存する度に少しずつファイルが大きくなって行くというもので、今 300MB くらいになってるんだけど... という事で申し訳ないです。
長年放置してたので言ってもしょうがないけど、オーディオ系 GUI 作成に特化しているから今でも割と使いやすいとは思っているのだけど。ただ Win 専用だし、書き直すなら Web アプリにしたい所なんだけど、ファイルの互換性を維持とか、ちょっと大変そうなんだよな。
Posted by g200kg : 2:18 AM : PermaLink
2019/01/28 (2019年01月 のアーカイブ)
MIDI 2.0 の件
さて、例年どおり開催された世界最大の楽器ショー NAMM 関係のニュースもほぼ出そろったようです。
島村楽器さんの記事とかRockOnさんの記事はまとまっていて読みやすいですね。見れば大体どんなものが出てきたかがわかりますが、気になるものはあったでしょうか?
私としては Teenage Engineering のモジュラー組み立てキットとか気になりますが。
そしてもうひとつ NAMM の直前くらいからニュースが流れていた「MIDI 2.0」の話。38 年ぶりに MIDI の規格がバージョンアップするという事です。といっても、「今やってます、名前は決めました」というニュースなので、これを搭載した製品が出てくるにはもう少しかかると思いますが、NAMM ではプロトタイプのデモなども行われたようです。
MIDI-CI
MIDI 2.0 に先立って昨年「MIDI-CI (MIDI Capability Inquiry)」という規格を作っているというニュースが流れていましたが、これとの関係としては MIDI-CI は MIDI 2.0 の一部として入口部分にあたるものになっています。下の図が MMA のサイトなどで公開されていますが、MIDI デバイスはまず MIDI-CI によってお互いにネゴシエーションを行い、MIDI 2.0 に対応している場合はそれを使って更に設定などの情報をやり取りする、対応していない場合は今まで通りの MIDI 1.0 デバイスとして接続する、という事を表しています。
MIDI 2.0 の基本的なコンセプトとして、3つの「B」と3つの「P」なるものがあります。
3つの「B」の1つが「双方向 (Bi-Directional)」です。今までの MIDI が一方通行で送りっぱなし、送ったメッセージが届いたかどうか、そもそも送り先にデバイスが存在しているかどうかがわからなかったのに対して、MIDI 2.0 では相手のデバイスとの間で双方向のやり取りをする事になっています。そして2つ目の「B」が「下位互換 (Backward Compatible」、つまり MIDI 1.0 の機器を繋いでもちゃんと動作する事。まあ、これを大事にしていたから MIDI はここまで生き残れてきたので当然の戦略ですね。
そして3つ目が「両方やる (Both)」。新しい MIDI 2.0 部分だけ作って MIDI 1.0 部分は手付かずというわけではなく、MIDI 1.0 相当部分にも可能な改善は加えていくという意味のようです。
そして双方向通信を使ってお互いが MIDI 2.0 に対応しているかどうかというネゴシエーション以降になる 3 つの「P」の部分が「プロファイル・コンフィグレーション (Profile Configuration)」「プロパティ・エクスチェンジ (Property Exchange)」そして「プロトコル・ネゴシエーション (Protocol Negotiation)」ですね。
プロファイルは自分が何の機器であるかを端的に表す属性を示すもので、自分は「オルガン」だよ、とか「アナログシンセ」だよ、という風に宣言する事で例えば「オルガン」ならドローバーの設定などを共有したりできるようにするというものです。
そしてプロパティエクスチェンジは、どんなパラメータを持っているかの詳細をやり取りするもので、今までの MIDI 機器でいえば、繋ぐ機器に応じたMIDI コントローラのセットアップとか、MIDI デバイスの MIDI ラーンの機能を自動化する事を目的としています。なおこれは、MIDI-PE と略される事はあるみたいですが、MPE だと MIDI Polyphonic Expression の略で、後述する ROLI の Seaboard なんかがサポートしている ノート毎のアーティキュレーションを指す機能の事になります。ちょっとややこしい。
3つ目のプロトコル・ネゴシエーションはこの双方向通信によって MIDI 1.0 デバイスと MIDI 2.0 デバイスを振り分ける仕組み自体をさしています。
ボイスメッセージ関係
ここまでは、MIDI-CI の周辺になる双方向関係の部分ですが、今回のニュースでは今までの MIDI の不満点として良く言われるベロシティのレゾリューションの不足への対応やチャンネルの増設などにも触れられています。
1 本のケーブルで 16 チャンネルに対応するというのが MIDI 1.0 の規格でしたが MIDI 2.0 では、1 本のデータのストリーム内に MIDI 1.0 または 2.0 として使用できる 16 個のグループがあり、各グループが 16 チャンネルを持っている、つまりトータル 256 チャンネルという事になります。
| Group | |||||||||||||||
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| MIDI 1.0 | MIDI 2.0 | MIDI 2.0 | MIDI 1.0 | MIDI 1.0 | MIDI 2.0 | MIDI 2.0 | MIDI 2.0 | MIDI 1.0 | MIDI 2.0 | MIDI 2.0 | MIDI 2.0 | MIDI 2.0 | MIDI 1.0 | MIDI 1.0 | MIDI 1.0 |
ベロシティやコントロールチェンジのレゾリューションも拡張されて軒並み上がってますね。これらは MIDI 1.0 にも相当する機能が存在していますが、レゾリューションが拡張されています。記憶ではたしか MIDI 1.0 でも高精度ベロシティプリフィックス (14bit) とか一応あったと思うのですが、全然使われてなかったようです。
| MIDI 1.0 | MIDI 2.0 |
|---|---|
| ベロシティ 7bit | ベロシティ 16bit |
| ポリ・チャンネルプレッシャー/ピッチベンド 7bit | ポリ・チャンネルプレッシャー/ピッチベンド 32bit | 16384 RPN (14bit) 16384 NRPN (14bit) | 16384 レジスタードコントローラ (32ビット) 16384 アサイナブルコントローラ (32ビット) |
| 128コントロールチェンジ (7bit) | 128 コントロールチェンジ (32bit) |
そして MIDI 1.0 とは互換の無い形で新規に追加されるメッセージもあります。8bit の型と 16bit のデータを持つアーティキュレーション情報、256 種のレジスタードコントローラと 256 種のアサイナブルコントローラ。今までのコントロールチェンジがチャンネル毎にまとめて対応なのに対して、これらはノートの 1 音 1 音毎に対応するもので、「5 次元キーボード」という触れ込みで話題だった ROLI の Seaboard がサポートしている MPE に相当するもの、VST で言えば Note Expression のようなものになると思います。
| MIDI 2.0 Messages |
|---|
| アーティキュレーション タイプ (8bit) データ(16bit) |
| 256 拡張レゾリューション・レジスタードコントローラ (32bit) 256 拡張レゾリューション・アサイナブルコントローラ 拡張レゾリューション・パーノート・ピッチベンド (32bit) |
これだけのものを規格としてまとめるのはなかなか大変そうです。流石に 38 年経って古いといわれる MIDI 規格ですが、MIDI 2.0 も長く使える規格になって欲しいですね。
Posted by g200kg : 2:17 PM : PermaLink
2019/01/26 (2019年01月 のアーカイブ)
WebAudio.tokyo #7 が開催されました
昨日 1 月 25 日に渋谷で 7 回目となる WebAudio.tokyo が開催されました。
内容は LT が 5 本 + 飛び込みです。ピアノロールの実装とかシェーダーを使った VJ エフェクトとかシャトルラン用プログラムとか。ヒューマンビートボックスと 88 鍵 キーボードでプログラムを書く話が印象的でした。
LT枠がなかなか埋まらないみたいだったのでつい埋めに行ってしまったけど、なぜかこのイベントは飛び込みで面白いものを持ってくる人が多い印象です。
ちなみに私からのネタは「ConstantSourceNodeの話」です。内容は WebAudioAPI には「ConstantSourceNode」という目立たない地味なノードがあるのだけど、これが実は Envelope Generator ノードとして動作するという話です。
この辺のノウハウ的な話は他にもいくつかあるので暇を見て「Web Audio API 解説」に追加しておこうと思います。なお、Web Audio API 解説もサンプルコードが古くなったりしていたので現状にあわせて更新中です。
デモで使ったプログラムはこちら :
ただし、現在 Release チャンネルの Chrome 71 では、ある操作をするとブラウザがハングアップします。Canary の Chrome 73 ではなおっているので降りてくるのを待ち状態。
Posted by g200kg : 4:34 PM : PermaLink
...更に以前の記事...
g200kg