96 Points Wine Advocate アンドレ・クルエ アン・ジュール・ド・ミルヌフサンオンズ 1911 グラン・クリュ・キュヴェ [NV] ANDRE CLOUET UN JOURS DE 1911 Grand Cru Cuvee【2本以上送料無料】

: サイト内検索

メーカー希望小売価格15,554円(税込)が
SPECIALPRICE￥11,770円(税込)
お得な24.4％OFF！

※1～5倍ポイントが付く場合の
送料無料は全国送料無料とさせて頂きます。
※6～10倍ポイントが付く場合の
送料無料は580円迄とさせていただきます。
※商品合計金額33,000円(税込)以上の
ご注文は1配送全国送料無料となります。

■ヴァン・ムスーとは？■
ヴァン・ムスーは、シャンパン、クレマンともにスパークリングワインで、
フランス語ではヴァン・エフェルヴェサン/Vin effervescent、ヴァン・ムスー/Vin Mousseuxdesuです。

シャンパーニュ以外で造られたフランスの発泡性ワインは、
すべて「ヴァン・ムスー」と呼ばれています。

「クレマン」は、瓶内二次発酵であることと、ティラージュ後９カ月以上
熟成させることが義務付けられているスパークリングワインです。

ヴァン・ムスーが、シャルマ方式など他の発酵方式でもかまわず、
熟成期間も、ほとんど制約がないこととの、大きな違いです。

◆シャンパーニュ方式/Methode Champenoise/メトード・シャンプノワーズ◆
瓶内二次発酵方式。最初の発酵に続き、２度目の発酵も瓶内でさせる製法。
トラディショナル方式とも呼ばれる。

◆シャルマ方式/Methode Charmat/メトード・シャルマ◆
タンク内二次発酵方式。密閉タンク方式（Methode Cuve Close/メトード・キュヴェ・クローズ）とも呼ばれる。
スティル・ワインをタンク内で二次発酵までさせてから瓶詰めする製法。
一度に大量に造ることが出来るので、コストを抑えることが出来る。シャルマは発案者の名前。

◆トランスファー方式/Transfer Methode/トランスファー・メトード◆
一旦瓶内二次発酵させた炭酸ガス含有の発泡性ワインを加圧下のタンクに空け、
冷却・濾過してから新しいボトルに詰め替える方式。シャンパン方式のルミュアージュと
デゴルジュマンを簡略化したもの。

■シャンパンの分類■

スタンダードなシャンパンは、
通常、黒ブドウ：白ブドウ＝7：3の割合で造られますが、
これらのブレンド方法と製造方法の違いで複雑な香味を醸し出すと共に、
以下のように、白からロゼまで仕上がり方が変わります。

■色による分類■

◆ブラン・ド・ブラン/Blanc de Blancs◆
白葡萄であるシャルドネだけから造られたもの。

◆ブラン・ド・ノワール/Blanc de Noir◆
黒葡萄であるピノ・ノワールとピノ・ムニエだけで造られたもの。

◆ロゼ/Rose◆
通常のロゼは醸造段階で黒葡萄の果皮を漬け込んで造ることを義務づけられて
いますが、シャンパンだけは、出来あがった白ワインに赤ワインを
ブレンドしてロゼにすることが認められています。

■味による分類ドザージュ/Dosage■

味については、ドザージュの際のリキュール・デクスペディションの
添加量により、甘口～辛口までの6段階に分類され、
「ブリュット」や「セック」などと表現されています。

「ブリュット（brut）」は「生のまま」という意味で、
ほとんど加糖されていない辛口のものをいいます。

これに対して「セック（sec）」は「乾いた、さっぱりした」
という意味で、シャンパンとしては比較的甘口なものをいいます。

また、最も甘口なものはドゥ（doux）と呼ばれるほか、幾つかの製造者は
ブリュットよりも辛口のエクストラ・ブリュット（extra brut）と
呼ばれるものや、あるいは、砂糖（甘味）を添加しないものも造っています。

◆エクストラ・ブリュット/Extra Brut◆
（極辛口）リキュール・デクスペディション添加量0～6g/l

◆ブリュット/Brut及びナチュラルNatural◆
（辛口）リキュール・デクスペディション添加量6～15g/l

◆エクストラ・セック/Extra sec及びエクストラ・ドライExtra dry◆
（半辛口）リキュール・デクスペディション添加量12～20g/l

◆セック/Sec及びドライ/Dry◆
（半甘口）リキュール・デクスペディション添加量17～35g/l

◆ドゥミ・セック/Demi sec◆
（ハーフ・ドライ/Half dry甘口）リキュール・デクスペディション添加量33～50g/l

◆ドゥ/Doux◆
（スイート/Sweet甘口）リキュール・デクスペディション添加量50g/l～

なお、リキュール・デクスペディション（liqueur d'expedition）を添加しない
ノン・ドザージュの場合は次のような表記がなされることがあります。

「Brut Zeor」「Brut 100%」「Brut Non Dose」「Ultra Brut」「Brut de Brut」「Brut Sauvage」

※ワインの知識とサービス 浅田勝美 著 柴田書店より掲載文抜粋

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

最近の記事

関連記事

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月 のアーカイブ)

96 Points Wine Advocate アンドレ・クルエ アン・ジュール・ド・ミルヌフサンオンズ 1911 グラン・クリュ・キュヴェ [NV] ANDRE CLOUET UN JOURS DE 1911 Grand Cru Cuvee【2本以上送料無料】

先日、「耳の話」なんかを書いたのでその辺りの話をもう少し書いてみます。

耳の奥、蝸牛は 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月 のアーカイブ)

96 Points Wine Advocate アンドレ・クルエ アン・ジュール・ド・ミルヌフサンオンズ 1911 グラン・クリュ・キュヴェ [NV] ANDRE CLOUET UN JOURS DE 1911 Grand Cru Cuvee【2本以上送料無料】

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

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

Web Serial API 日本語訳 公開

さて、先日 "Web Serial API" について少しだけ書いたのですが、この際なので仕様書を日本語訳しました。
GitHub に置いてあります。

本編の他に付属文書としてもう少し簡単な手引書がありますので、取り合えず動かしてみたい、という場合にはそちらを読むのがはやいと思います:

Web Serial API (日本語訳) Draft Community Group Report
Web Serial API (日本語訳) 手引書

W3C 勧告に至る TR (Technical Report) ではなく、W3C Web Platform Incubator Community Group の Draft Report ですが、3月に安定版になる Chrome 89 以降、フラグ設定なしでデフォルトで使えるようになります。

前も書きましたけど、こういうハード系に近いブラウザ API が色々出てきていると同時にセキュリティ面の風当りは強くなりつつあり、将来的にどうなるかはさっぱりわかりませんが、ハードウェアに手が届く何らかの手段は生き残って欲しいところです。

Posted by g200kg : 7:00 AM : PermaLink

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

Web Serial API

現在 Chrome の安定版のバージョンは 88 ですが、3月に入るとそろそろ Chrome 89 が安定版に降りてくる予定になっています。それで、Chrome 89 では工作系の人にとってはちょっと気になるかも知れない 「Web Serial API」という ブラウザ API がフラグ無しで使用可能になります。まあ今でも "chrome://flags" で "Experimental Web Platform features" を "Enable" にすれば使えるようになるんですけどね。 なお、88 ⇒ 89 で USB デバイスの接続/切断あたりのイベントの仕様に少し変更があるので、本格的に使うなら Chrome 88 でフラグをイネーブルするよりは 89 を待つか Chrome BETA で試した方が良いかも知れません。

Web Serial API の仕様書はこちらにあります。

Web Serial API (W3C 英文)
Web Serial API (日本語訳)

それで、これで何ができるかというと、Web アプリから PC のシリアルポートを直接叩けるようになります。 Ardiono とか micro:bit とかの IoT デバイス等と Web アプリが繋がるというあたりがメインターゲットになるようです。とは言っても、WebUSB API と言う USB に繋がっているものなら何でも制御しようとしているもっとヤバい API が既にあるので、そこまでインパクトは強くないかも知れませんが。

WebUSB との違いとしては今となってはレアかも知れませんが USB 接続じゃないシリアルポートも制御対象になります。それから USB 経由のシリアルポートを Web USB から叩いて動かすのは、シリアルポートの立場から見れば API の上層をスキップして中間層をいきなり叩かれる事になるのでシリアルポートは Web Serial API からシリアルポートとして叩くというのが行儀のよい使い方、という事のようです。

実際に動作する例として googlechromelabs に Web Serial API で作ったシリアルターミナルのデモがあります。
https://googlechromelabs.github.io/serial-terminal/

使い勝手としては、機能をシリアルポートに絞っている分シンプルですね。ポートを requestPort() で選択したら open() / close() する感じで、データの送受信は port オブジェクトの readable、writable 属性からストリームとしてアクセスして行います。また、DTR や RTS 等の制御線は setSignals()、getSignals() でコントロールできます。

なお、最近のブラウザのセキュリティポリシーの強化の流れもあり、最初にポートに接続する際には下のようなプロンプトが表示されるので、ユーザー自身が直接選択の操作を行う必要があります。一度許可したポートは覚えているようなので、USB経由のポートの場合 getPorts() で現在アクセスできるポートの列挙ができます。

この Web Serial API ですが、現在は W3C の "Web Platform Incubator Community Group" で議論されていて、いわゆる W3C 勧告に繋がる標準化のラインには載っていません。なので残念ながら Chrome 以外のブラウザで対応するという話も今の所ありません。特に Apple はセキュリティ面を懸念して Web MIDI にも否定的でしたしね。 こういう物理デバイスに届く API はなかなか標準化される所まで行くのは難しいと思いますが、ちょっと何か簡単に外部デバイスを繋ぎたいという時には重宝しそうだと思います。

Posted by g200kg : 3:26 AM : PermaLink

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

Web Audio API (日本語訳) を更新しました

W3C で公開されている Web Audio API (CR) が 2021年1月14日に更新されましたので、日本語訳も対応して 2021/01/14 版に更新しました。

今回更新した版も W3C 勧告候補 (CR, Candidate Recommendation) 版となっています。

2020年6月に更新されて以来ですが、内容的には細部の説明の追加や修正等で機能面での変更はありません。流石にもうほぼ安定していて今までは更新の度に内容が大移動したりしていたのですが、今回は章立てレベルで変わったのは AudioWorklet 関係で説明が追加になった箇所だけです。

今後の流れとしては、大きな問題が出てこなければ現在の 勧告候補 (CR) から 勧告案 (PR) を経て正式な W3C 勧告となるはずです。

Web Audio API (日本語訳)
Web Audio API : W3C の英語版 ページ

間違いなど見つけたら GitHub issues へお願いします。

Posted by g200kg : 11:09 PM : PermaLink

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

Web Audio API の勧告候補がアップデート

W3C で公開されている Web Audio API の勧告候補 (CR) が 2021年1月14日版にアップデートされています。

アナウンス : https://www.w3.org/blog/news/archives/8867
公開ページ : https://www.w3.org/TR/2021/CR-webaudio-20210114/

前回が 2020年6月11日 版でしたので半年と少しぶりですね。今回も Candidate Recommendation、勧告候補という位置付けなのは変わりません。前回からの変更点はChange Logを見ればわかりますが、GitHub の issue で議論されていた点などが反映されています。

変更点の詳細 :
Change Log : Since Candidate Recommendation of 11 June 2020

基本的に細部の説明の追加や間違いの修正ですので機能的に変わっている点はないと思います。
今後は少なくとも2021年2月15日までは勧告候補のままで更なるフィードバックを求める、という事です。

※ 通して読んでみると worklet の説明とかで今まで "Javascript" だったのが WASM でも行けるぜという事で単に "Script" になってたりしますね。他には最近の流れの関係で "master" という単語を "main" で置き換えたりと機能的には変わりませんが細かな違いは結構あります。

Posted by g200kg : 5:30 PM : PermaLink

---

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

g200kg