サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
ドラクエ3
lowreal.net
結論からいうと ここでいう「微妙な音ずれ」はサンプルレート48kHzで、1分あたり18サンプル(=0.4ms)のもので、普通は気になるものではない。 これは原理的になくせないずれである。 経緯 OBSで複数のUSBオーディオデバイスからの音声をマルチトラック化して録画データにくっつけている。アナログで同じ音声を入力している別々のデバイスの2つのトラックの音を細かくあわせてみると、デバイス間で徐々に広がる遅延があることに気付いた。あまり大きい量ではないが、気持ち悪いので一旦調べてみることにした。(詳しい人はこの時点でそりゃダメじゃんと思うだろうが……) だいたい1分で18サンプル(=0.4ms)ぐらい進んでいる。2分ならもっとすすむ (数えるのが面倒だけどだいたい倍ぐらい)。 追試として、同じアナログ入力をしている2つのインターフェイスを同時にOBSで録音して、録画開始直後に同期をとり、その
ちょうど1年前からギターの練習をしている。別の日記つくって記録している https://itisnevertoolatetolearn.hatenadiary.jp/ 関連してつくったもの 100万回ぐらい再発明されていると思うけど、いまいちウェブ上で使えるこれだというのがないので自分でかいたやつ Lookup chord from fretboard 指板ポジションからコード求めるやつ スケールをオーバーレイさせて、同じ構成音で別のおさえかた探すときにも使ってる 指板のボックスポジション一覧 CAGEDの各ポジション覚える用。なんか拾ったPDFを印刷していたが、他のパターンが欲しくなったのでつくった。 ボックスは覚えたのでほぼ使ってない Lookup scale from notes or chord コードか構成音からどのスケールか推定するやつ キーがよくわからんとき、いろいろ情報量増
液晶風の画面は決まった形をオン・オフするだけなので、canvas にコードで描くのは大変なだけで無駄が多い。かといってセグメントを1つ1つ画像にわけて座標指定で配置していくのも面倒くさい。 と考えていくと SVG を埋めこんで、SVG の要素を JS で操作するのが効率が良い。ワークフローとしては SVG の作成と JS の実装で綺麗に境界を作ることができる。 Inkscape Inkscape の良いところは以下の点 XML エディタが UI と連動している レイヤーやオブジェクトを選択すると該当箇所にエディタ上で跳べる 構造をコントロールしやすい 画像を編集するというより SVG の XML を編集するUIというイメージ Inkscape でオブジェクトに名前をつけると、svg 上では inkscape:label 属性に入る。これを利用して JS から操作すれば Inkscape で
スケボーちょうど90日目 プッシュすらろくにできなかったことを考えると成長している…… pic.twitter.com/DYe5RC4it9 — 8Kは福祉 (@cho45) July 8, 2022 だいたいこのへんを練習していた エンドウォーク エンドオーバー ドッグウォーク 深いターン(スイッチも) パンピング フロントサイドパワースライド バックサイドパワースライド ヒッピージャンプ ケイブマン (ランニンニングノーズピックアップ～飛びのり) オーリー エンドウォーク・エンドオーバー エンドウォーク・エンドオーバーは徐々に安定はしてきた。まだ力んでしまう。無駄な動きがなくなっていっている感じがする。これメインで練習することが減ってウォーミングアップにまずエンドウォーク・エンドオーバーという感じ。 ペニーのエンドウォーク pic.twitter.com/r3tYFMtZBy — 8K
Windows PowerToys の Keyboard Manager を使って macOS 風のキーバインドを導入するというのをやっているけど、これをすると WSL2 が快適になる代わりに PowerShell が不便になるという問題があった。具体的には、Up/Down キーで ^P ^N が入力されてしまうので履歴が辿れないなど。 これは実は簡単に解決可能で、 Set-PSReadLineOption -EditMode Emacs として PowerShell 上のキーバインドを emacs 風にするだけでよい。これで Ctrl-P / Ctrl-N などが適切にマッピングされるようになる。 毎回実行するのは面倒なので、echo $PROFILE で出てくるファイルパスに以下のように書いておくと良い。 echo "Running $PROFILE" Set-PSReadLineOp
2016年にウェブ縄文時代がどうこう書いたけど最近どうやらウェブ縄文時代が本当にきつつあるみたい、と書こうとしたら既に morygonzalez さんが書かれていた のであまり書くことはない。縄文時代というか、個人サイトへの回帰という話だけど、観測範囲のブログやら日記がASPホスティングから個人サイトに移行したりしている。 知り合いとチャットしていて教えてもらったけど、国内だけの事象というわけではないみたいで、今年の6月には The Return of the 90s Web という記事が書かれていた。不思議な潮流。 2017年に個人サイトは終わってしまったのかと書いたことがあるけど、終わってないかもしれないので嬉しい。このエントリでも触れてるけどASPホスティングの個人ブログも、セルフホスティングの個人サイトも境界は技術的には曖昧で、しいていえばコンテンツを自分で所持しているといえるかど
Google Photos が発狂してからと書いてから、いろいろ見積って画像をセルフホストすることに決めた。とにかくアップロード機能はあとで作るとして、現状の画像が表示されていない状態を是正しなければならない。つまり Google Photos に上がっている画像のうち、日記で使われている画像をこのホスト上にコピーして配信する必要がある。 事前知識 まず Google Picker API 経由で取得した media の id や URL と、Google Photos API は一切互換性がない。もともと念のために Picker 経由で取得した ID っぽいものは保存していたのだけれど、これはまったく使えない。よって、Google Photos 上の全写真のメタデータをすべて取得し、ファイル名マッチによって画像を特定 (つまりファイル名→Google Photos mediaId のマッ
↑この画像は静止画ではなく、録画のスナップショット (α7R II 2160p モードを CamLink 4K/30FPS NV12 でとりこみ) 結論からいうと CamLink という HDMI → UVC 変換器 (キャプチャボードの一種) を使うのがおすすめ。カメラの HDMI 出力と繋ぎ、カメラ側は動画モードにして、HDMI INFO の設定 (HDMI に OSD を出さない) をするだけでよい。 カメラ側で HDMI 出力設定を変えて 1080p か 2160p かを選べる機種の場合は、カメラ側で設定を好みのほうに変える必要がある。デフォルトだと 4K でしかとれないので、1080p で十分なら下げたほうが負荷が低いと思う。 もっと安い HDMI USB キャプチャあるけど? 知ってるぞ！ こういうのだろ！ HDMI → UVC 変換器もピンキリで、キャプチャできる解像度や、画
概要 無線機の出す I/Q 信号をサンプリングして 2ch (ステレオ) としてコンピュータに入力し、これを直接 WebAudio から扱って音声までデコードする。ソフトウェア側はブラウザだけで完結する。 実用レベルではないが SSB の復調まではできたので一旦記録しておく。 レポジトリ https://github.com/cho45/webaudio-sdr 前提条件 入力 無線フロントエンド(アンテナや局発ミキサなどのハードウェア)が必要になるが、それは用意されていて、PCへの入力は2chのステレオマイク入力として行われているものとする。 自分の環境では KX3(無線機) のアナログ I/Q 出力を USB Audio Device のマイク入力に入れてサンプリングしている。 何を実現できればいいか 最初の要件を定義する。 SSBモードをUSB/LSB 指定で音声をデコードできること
Terrarium は Fastly の WebAssembly を実行してくれるお試し環境みたいなやつ。ちょっと前に話題になった Lucet が使われているらしい。何のログインもなく使えて、デプロイできて「お、おう」って感じ。デプロイすると15分だけアクセスできる。 ちょっとリファレンスを見てみたところ KVStore というのがあってパーシステントな (ただし15分だけ) 状態も持てる。ということでとりあえずカウンタを書いてみた。 Rust に不慣れなので不必要なコードとかもっとうまく書けるところがありそう。 #[macro_use] extern crate http_guest; use std::fmt; use http_guest::{Request, Response, KVStore}; pub fn user_entrypoint(kvs: &mut KVStore,
パタパタ時計 (flip clock) ebay で 1300円ぐらいで買った。デザイン上不可解な点があるが一応そこそこ動いてくれる。パーツが多い製品になりがちなのでこれ以上安いものはないみたい。 ちなみにパタパタ時計は以下の点で優れている 直読可能 (vs アナログ時計) 12時間アナログ時計のように読みかたのリテラシがいらない 数字の形が自然 (vs 7セグメントデジタル時計) 高コントラスト (vs 液晶) このような特徴から、子どもでも読みやすい。一方で秒単位の正確な表示はできない。 この製品の場合1時間に1度バネの復元によって「時」を送っているため割と大きな音がする。分送りではあまり音はしない。秒針のカチコチ音はする。 構造 普通のクオーツ時計だが、使っているのは分針の動きだけになっている。時針はムーブメントに存在しておらず、流用と思われるムーブメントも内部のギアが一部省かれてい
考えてみるとほとんどパスワードを保存するコードを書いたことがない。現状のベストプラクティスを知らなかったのでメモ書き。 現状では bcrypt 使うのがいいみたい。b は Blowfish の b。 Modular Crypt Format というフォーマットとコンパチの出力をする。crypt (3) はもともと DES の短いフォーマットだが、弱すぎたため md5 拡張なりSHA512 拡張などが存在している。(htpasswd でも使われているので見たことある人は多いだろう) これの Blowflish を使ったものが bcrypt で、prefix に $2$, $2a$, $2x$, $2y$ $2b$ がついている。prefix の違いはバージョンの違いであり、現在は 2b を使うのが良い。ストレッチング回数も出力に含まれるので、あるとき急にストレッチング回数を増やしても特に問題
現在の非表示ユーザの総数: javascript:(async()=>{alert((await(await fetch("http://b.hatena.ne.jp/my/ignore.json")).json()).ignore_users.length) })() http://b.hatena.ne.jp/api/my/ignore_users のほうが簡単(あたらしい)っぽい。上のAPIと数が違う。プライベートユーザを含まないとか？ ↑ は405 で動かなくなっていたよくわからない。下のは動く javascript:(async()=>{alert((await(await fetch("https://b.hatena.ne.jp/api/my/ignore_users?limit=10000")).json()).users.length)})() 選択範囲に含まれるブクマユ
1x4 / 2x4 用の突っ張りアジャスターは1セット1000円弱とそれなりに高い。必要なものが木材以外はセット (アジャスタとすべり止め脚) なので便利なんだけど、安くあげたい。ちなみに 1x4 用も 2x4用もあまり値段が代わらない。 必要なもの 材料 アジャスタボルト M8 50mm〜100mm 約半分は材の中に入るようにする。なので60mmなら30mm突っぱれる 180円〜500円ぐらい ヨドバシだと スガツネ工業 ADWH40-8-60 は少し高いがメッキされていて質感が良く、ゴムもついている。 トラスコ中山 TRUSCO NF8X100 は普通のやつだけど少しやすい。 ハンズだと単体のアジャスタボルトが180円ぐらいで売ってたりもする。 M8 ワッシャー 1枚10円ぐらい M8 スプリングワッシャー 1枚10円ぐらい M8 ナット アジャスタボルトについてる場合は必要ない すべ
Aliexpress を利用しているとサインイン時に自動的にログインする仕組みが導入されていることに気付く。知らない人のために説明すると、以下のような挙動をする。 ログインページにいくと「Google Smart Lock で保存したアカウントを使ってログイン」というブラウザのUIが表示される そのまま「ログイン」ボタンを押すと自動的にサイトにログインしてページ遷移する セッション切れのときに My Orders などにアクセスしようとすると、一度ログインページに遷移した後、自動的にログインして My Orders ページに遷移しなおす (ログイン済みになって見れるようになる) あまり他のサイトだと見ない挙動なので最初は驚いたけど、便利。 仕組み これは Credential Management API という仕組みを使うと実現できる。現状では Chrome しか対応していないようだ。G
「無反射ガラス」って名前がかっこいいんだけど「ノングレアガラス」というともうすこし実体がわかりやすい。すりガラスの目の細かいもののことで、つまり表面が細かくざらついており光を散乱させるので反射が少なくみえる (全体としての反射の量には変化がないが、散乱させるので特定方向へ反射させる量は減る) ガラスは割れる・切れるで若干扱いにくいので、あまり使いたくはない。ということでアクリルで似たようなものはないか？と探してみると、東急ハンズで普通にノングレア・つや消し加工されたアクリル板が売っていた。カナセライトの「クリア(つや消し)」というもの。 t=2mm のものを買ったけど、270x320mm でも思ったよりもたわむので 3mm ぐらいはあったほうが良さそう。 調べてみるとカナセライトはマット以外にノングレアというおそらくもっと細かい目のタイプも作ってるようだ。アクリル板マット板、アクリル加工専
やってること prometheus の API を叩く 表示する だけ。 表示部分はせっかく python の骨格があるので基本的にはそのまま python で書いてる。けど Pillow (python の画像処理ライブラリ) はそれほど高機能というわけではなくて、文字表示時に細かいオプションが一切指定できなかったりするので Ruby と Cairo とか慣れた他の方法でやったほうがよかったかも。 フォントは Noto Sans CJK の Black。Pillow が OTF をちゃんと読めてよかった。 表示はフルリフレッシュを避けるように数値部分だけを部分書き換えしている。これにより表示更新が早くなるのと、フルリフレッシュ時みたいな全体が反転するチラツキがなくなるので常時していても邪魔くさく感じにくいはず。 部分書き換え (partial update) ↑ 試している様子 (値はラ
HS105 を買ってみた。中にリレーが入っていて Wi-Fi 経由でオン・オフできるというもの。 値段的には3000円ぐらいで買ったので、まぁこのぐらいだろうという気がする。まともな24時間タイマースイッチと同じぐらいの値段と考えると、買える値段。定価だとちょっと高いなと感じる。 アプリからのオン/オフは結構はやい。リレーの動作音 (カチ) がするので、リレーの動作音が好きな人(自分)には嬉しい。 最大電流が14Aまでだけど、14A限界まで連続して使うような負荷には使わないほうが良さそう。今のところエアコンと連動させたいサーキュレータに使っている。 うちでは他に使えそうな機器があんまりないかな。冬になったらホットカーペットに使うのが便利かも。あとはいざってときに強制的に再起動したい機器につけとくと遠隔で再起動できて良いかもしれない。 Google Home から制御 デバイスは TP-Li
127.0.0.1 より localhost のほうが書きやすいし良さそう、と思って localhost と書いているとしばしばハマります。 というかなんとなく localhost = 127.0.0.1 と考えがちではないでしょうか？ そんなことはないので気をつけましょう。 最近のシステムなら /etc/hosts を確認すると少なくとも2つの localhost エントリを見ることができるでしょう。 127.0.0.1 localhost ::1 localhost 上は IPv4、下は IPv6 です。localhost はどちらのアドレスにも解決しうるホスト名となっています。 どういうときにハマるか 例えば同一サーバでリバースプロキシを行ってバックエンドサーバと繋ぎこみを行う場合、フロントのリバースプロキシで localhost:5000 と書くと IPv4 IPv6 どちらでアク
αシリーズ(？)は電子先幕シャッターがデフォルトだが、デメリットがわかりにくいので調べた。 電子先幕シャッター自体の説明はググったほうがわかりやすいが、一応以下のように比較してかるく説明しておく。 シャッター方式はいくつかあって (フル) フォーカルプレーンシャッター： 一眼レフカメラなどに採用されている。物理的な先幕・後幕がセンサー前を走るもの 電子先幕シャッター：基本的にフォーカルプレーンシャッターと同じだが、先幕を電子的に行う (センサーの電荷をクリアすることで前幕とする) 電子シャッター (サイレント撮影)：先幕も後幕も電子的に行う。先幕は電荷クリアで行い、後幕は連続した読み出しで行う 完全電子シャッターはレリーズラグがなく機械的に動く部分がないので静かなことが利点だが、センサー読み出し速度で律速されてローリングシャッター歪みが起こる欠点がある。 電子先幕シャッターは機械式フォーカ
mbed USBMIDI で Lightroom 用の MIDI インターフェイスを作る | tech - 氾濫原 の続きで、実際に使えるものを作りました。まぁもう作ったの一ヶ月ぐらい前なんですが…… 回路図 機械式インクリメンタルロータリーエンコーダー (スイッチ付き)を19個、Gateron 緑軸スイッチ (Cherry MX 互換スイッチ) 7 個を使います。ロータリーエンコーダーはA相・B相・スイッチと3接点あるので 19 * 3 + 7 = 64 接点あります。キリのいい数字ですね。 ロータリーエンコーダーのA相・B相も単にスイッチとみなせるので、ダイオードを使ったキーマトリクスを構成し、16bit I2C GPIO (MCP23017) 1つを使って順次全て読み出します。その際、同一エンコーダーのA相B相は同時に読めるようにマトリクスの配線に注意します。 USB を繋げるメイン
オペアンプ大全は2002年〜2003年ぐらいにアナログデバイセズによって書かれた本の日本語翻訳版で、ものすごい分量がある本。たぶんオペアンプ関係で一番まとまってる本だと思う。 で、とりあえず本題だけど今はAnalog Devicesのサイトで無料で PDF がダウンロードできる。(ただし個人情報の入力が必要)
仕事を中心にして考えてるのがそもそもの間違いだと思う。あたりまえだけど業務時間外は「自分の時間」であって、仕事のための勉強をする時間ではない。 前も書いたけど、趣味すなわち自分の時間で自分の意思によって主体的に行うことが一番重要なのであって、仕事はそれに付随しているものでしかない。 「趣味でやった結果がなんとなく仕事に役に立つ」は良いが「仕事のために趣味の時間を使う」のは間違えている。 僕が嫌だなと思うのは、趣味で好きでやってた結果仕事に役に立って金を稼いでいるケースなのにも関わらず、それを「努力」の結果だとしようとするところで、一見マトモそうな人でもこういうことを平然と言ったりするので気が萎える。あくまで、仕事に役に立つことに興味を持ってとりくんでいるのは「たまたま」なので、それでマウンティングかけるようなのはイライラしてしまう。 趣味と仕事が直結しているのは (たとえば自分もそうだけど
日記に「遅延公開」みたいな仕組みが欲しいなと考えている (今はない)。一ヶ月ぐらい遅延して公開したい。機能的には指定日公開機能ともいうが、インターフェイス的には「1ヶ月遅れで公開する」みたいになってる機能。ただし新しい記事として公開するのではなくて、書いた日付はそのままで「古い記事」として追加される。 これによって、公開された時点でその日記は既に「古い情報」であることが保証されるので、閲覧者にとっては直接的に言及しにくくなる。 情報感度がある程度高いような閲覧者に対しても、書き手と閲覧者との間で情報速度に必ず一定の遅延がかかるので、情報感度による閲覧者間での情報格差が減り、結果的に公平となる。 新しい情報が公開されたかどうかは、毎日全てのページを見て差分をとらなければわからないため、ウォッチャーみたいな人にとっては厄介という感じの機能になる。 基本的にトップページに露出することがなくなるの
ABS と PLA も試したけど PETG (Polyethylene terephthalate glycol-modified) が最良と思っている。 ABS のような反りがなく・寸法安定性が良い PLA ほど耐熱性が低くない ベッドへの接着性が高い・層間の接着性が高い 造形中に剥れて失敗することが少ない ベッドを必要以上に綺麗にする必要もない (基本的にスプレーのりもいらない) 価格的にもABS・PLAとそれほど変わらないか少し高価な程度 強度もあるが硬すぎるというほどでもなく割れにくい (靭性がある) プリント後の加工も可能 ABS よりは加工性が悪いが、PLAのような苦労はしない 臭いがほとんどない (ABS みたいな臭さもないし、PLA みたいな甘い臭いもしない) ノズルが詰まりにくい気がする (PLA は詰まりやすい) 一方でPETG独特の問題もある 条件によって糸ひきが多い
Sequel はドキュメント見ると SQL そのまま書くやりかたもとクエリビルダを介すやりかたも許されていると感じるので (別に他のライブラリでも可能だろうが)、導入負荷が低くてよさそうです。結構機能はもりだくさんありますが必要なければ使わないのも許されてる感じもよさそうです。 Sequel でのクエリ発行のしかたは sequel/querying.rdoc at master · jeremyevans/sequel · GitHub を読むとだいたい網羅できるが、特に自分に重要なところだけ別途メモしておく。 モデルを使っても使わなくても SQL クエリはそのまま発行できる。複雑な JOIN も安心。 モデルを使わない場合 SQL を発行して Hash として取得できる。 dastaset = DB["SELECT * FROM foo"] dataset.all # 全インスタンス化
NKRO (N-key Rollover) というのは、おおざっぱに言うとキーボードのキーを同時押ししたとき、いくつ認識するか？ということです。 NKRO の理想的には以下の挙動になります。 いくつキーを押しても全て同時に押されていることがコンピュータから認識される これを NKRO として定義すると、全ての USB HID キーボードは NKRO ではありません。なぜなら、USB HID キーボードは修飾キーを除くと6キーまでしか押されていることを送信できないからです。 USB HID での NKRO そうすると妥協した次点として以下のような仕様を NKRO とするほかありません。 6キーまでは同時押しがコンピュータから認識される 7キー目を押すと、最初に押したキーが離されたと認識される 完全な同時押しは6キーまでですが、入力をとりこぼすということはありません。USB HID で NKR
BLE Nano を使っていた自作キーボードだったが、Mac のアップデートとともにまた不安定になってしまい、使う気を失ってしまった (数時間ごとに再ペアリングが必要に)。直す気力もなくてしばらく放置していたが、そろそろ観念して USB 接続のキーボードに作りかえることとした。 作りかえるといっても、キーボードの部分は I2C GPIO のモジュールとして動くように作ってあるので、マイコンまわりを載せ変えて実装を書くだけになる。 ということで、タイトルの通り LPC11U35 を使ってキーボードを実装しなおした。 コード: https://github.com/cho45/keyboard-lpc11u35 mbed official の USBDevice mbed official に存在するライブラリの USBDevice の中に USBKeyboard というのがある。USBHID
(画像は過去に入力したデータを全て Google Fit へ入力しなおした様子) Fit API 全体の概念 単純にグローバルな「体重」に対して値を追加するみたいになっているわけではない。 各アプリケーション(サードパーティ含む)は自分用の「データソース」を作る。これはセンサーに対応する。例えば「体重計 HOGE-001」みたいなデータソース。このとき「体重 (com.google.weight)」とかデータの種類と「浮動小数点」とかデータ型の定義をしておく。 データソースの定義に従って、データソースにデータポイントを追加してく。例えば「体重は 69.95kg」みたいな。 こうしていくと、複数のデータソースから「体重」データがいくつもできることになる。 実は Google Fit の画面から体重を入力すると user_input というデフォルトで存在するデータソースにそのデータは蓄積され
次のページ
このページを最初にブックマークしてみませんか？
『氾濫原 [HANRANGEN]』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
