ボタQ@bota9
映画「ファースト・マン」に日本の新聞が出てきた。ウチにも当時の新聞があったはずと探したら、ありました。中日新聞の号外。ボロボロですが、50年前のモノなので、ご勘弁。 https://t.co/YVypANULmW
人工知能・機械学習ニュース [公式]@A_I_News
100ページ以上の強化学習の資料が公開（日本語）
強化学習について分かりやすくまとめられています。
《対象読者》
・強化学習について知らない
・機械学習に興味がある
・生物学の分野出身でモデル生成の行動に興味がある
・ゲームを AI に解かせたい
@komi_edtr_1230
github.com/komi1230/Resum… https://t.co/pEmDu2nwR5
S.F.@SFPGMR
コード・パートも音色・フレーズとも長年の課題となっているものの一つ。まあまあかなあとか自分では思ってるんだけどね。。このコードの変化がなんともいえず好きなんだなあ。。一番好きなパートともいえる。。
youtu.be/IFLX9lbKDLY
最初のころPsycleというTrackerで作ってたんだけど、コード・パートのフレーズ全然違うな。しかもコード間違ってるよな。。恥ずかしい。。
Trackerちゅうのは昔のPCで流行った音楽作成ツールですわ。正確にはMOD Trackerという。。
ベース・パートはちょっとディストーションかけることで近い音が出るようになってちょっと喜んだ。間奏の低域で鳴らなくて困った音階があったけどそれは解消したんだよね。。
Youtube - Rydeenのベースパート
PsycleというTrackerの次はBUZZというので続きを作ってた。でも今聴くとなんか全然違うなあ。。しかしRydeenを作りはじめて20年近く経っても全然完成しないというのは何なんだろう。私って。。根気があるような、ないような。。
Youtube - YMO - RydeenをBuzzでカバーする（38）
これが2年前にアップした最新版？だけど、聴き比べると近づいていってるとは思うんだけどな。。
Youtube - YMO - RYDEEN (67)
ただリードパートがBuzzで作ったやつのほうがスタッカート気味でいい感じがしたけどな。
リードパートの音色が作れなくて悩んでる。ここでちょっとモチベーションの糸が切れて2年経ってしまった。。
これが悩み中のリード・パート。。
Youtube - Rydeenのリード・パート
Rydeenのカバー曲はYouTubeにいくつもアップされているけど、原盤雰囲気に近いな。。と思ったのはこのカバー。リード音とか言い音してるし何よりおそらく弾ける人がデータ作るとやっぱりリアルだなあと思うんだな。。
Youtube - Rydeen (YMO) for Reason 【Copy】
とりあえずの現状のリズム抜きでのアンサンブルはこんな感じ。間奏～ラストまで。。
なんか低音出すぎの気がしないでもない。。
ドラムはどこかにあったフリーのドラム音を引っ張ってきて「らしく」なるように作ってる。タイトにするためにノイズ・ゲートでスネアのリリースをバッサリ切ったりもしてる。
Youtube - Rydeen（ドラム・パーカッション）
ノイズ・ゲートかける前の音はこんな感じ。なかなかパワフルですな。。
Youtube - Rydeen（ドラム・ノイズゲートなし）
ほかのリズムパートと合わせるこんな感じになる。
ほかのパートでマスキングされたりして音が近くなるんだよな。。
Youtube - Rydeen（リズム・パート）
とりあえず成果物としてあげておこう。永遠に未完成な気もするこのカバー。
Youtube - YMO - RYDEEN (68)
今日聴くとリードの音色がまたオルガンみたいになっとるな。。ああ。。
expressで大きいデータをポストすると413エラーが出る件。結局この情報で解決した。
javascript - Error: request entity too large - Stack Overflow
I'm receiving the following error with express:
Error: request entity too large
at module.exports (/Users/michaeljames/Documents/Projects/Proj/mean/node_modules/express/node_modules/connect/
これ。
app.use(express.json({limit: '50mb'}))
body-parserを使うのはもう古いのかね。。
いずれにしろこれでこの問題はクリアした。
が今度はx-hub-signatureで問題発生
{"error":"No X-Hub Signature."}
Securing your webhooks | GitHub Developer Guide
Get started with one of our guides, or jump straight into the API documentation.
ペイロードのサイズが大きいと出るんだな。これがなぜか。。
原因はミドルウェアのuseの順序だった。。凡ミスだった。。
It needs to be one of the first and before bodyParser().
express-x-hub - npm
X-Hub-Signature Express Middleware
かえりの電車の中で一個バグを潰せたわ。。termux恐るべし。。
x-hub-signatureのチェックは自前でチェックしてもおそらく数行で済むから自前実装でもいいような気もするな。。
とりあえず一歩前進ですわ。あとはコンテンツを生成するテンプレートをアップデートしないといけない。あとは技術的なアップデートもせんといかんなあ。。
ページ・デザインももうちょっと頑張るか。。
しかしなんでプリロードしたらああなっちゃんたんだろうな。。
まあしかし、expressでホストしてもそこそこいけそうですわな。。そもそも私のサイトそんなにアクセスないし。。ちょっとさみしいけど。。
プリロードはプリロードする「だけ」なのですな。
link要素でpreloadを使って非同期にファイルを読み込む - はしくれエンジニアもどきのメモ
link要素でpreloadを使って非同期にファイルを読み込む link要素でpreloadを使って非同期にファイルを読み込むメモ． link要素でpreloadを使って非同期にファイルを読み込む preloadとは 現在の対応状況 resource hint 使用例 読み込み後，即時実行(Async Loder) preloadに対応しているファイル 参考リンク
<!— preload—>
<link rel="preload" href="style.css" as="style">
<link rel="stylesheet" href="style.css">
互換性を考えるとこう書くのが良さそうだな。。
CSSのプリロードを実施したが、スコアは変わらず。。 https://t.co/RY4BOuF7g4
モバイルは84点か。。 https://t.co/Bki0Iljv94
AMPページだと89点。。 https://t.co/P92tXvWEW6
AMPページはパソコン版でも99点。。 https://t.co/1Pwoe1SNPC
リード音を直した。。
Youtube - YMO - RYDEEN (69)
しかし同じページなのにPC版とモバイル版はなぜスコアが違うのか。。サイズによってレンダリングの仕方が異なるからかな。。いちおうレスポンシブだからね。。
さらにリード音のレベルとリバーブを深くし、バスドラのエンベロープとエフェクトを調整した。
Youtube - YMO - RYDEEN (70)
リード音だけ鳴らすといまいまはこんな感じ。。
Youtube - Rydeenリード音20190209
だんだん近づいてる気はしてる。。
「Behind The Mask」もREAPERで作り直したいんだけどな。手が出ない。これはBuzzトラッカーで作ってた時のバージョン。この時作ってた時のエフェクトデータが吹っ飛んでなくなったのが痛い。。
Youtube - YMO - BEHIND THE MASK (7)
久しぶりにブログを更新した。
S.F. Blog:静的サイトジェネレータのアップデート（nginx→express）
はじめに去年からWebサーバをnginxからexpressにアップデートした。途中放置気味であったがようやくまとも動くようになったので、テストを兼ねてこの記事を書くことにする。約8か月振りのブログ更新となる。静的サイト・ジェネレータ私が今使っているServers Man VPSは月額467円のエントリープラン、メモリ1GB/HDD50GBのものを使用している。最初はメモリ256MBであったがだんだ...
ちょっとだけアップデート
＜変更点＞
・Aメロのディレイビブラートを強めにした
・Bメロのリード音の音色を調整。音量を大きめに
・バスドラのエンベロープとスネアを微調整
Youtube - YMO - RYDEEN (71)
さらに見直し。。
Youtube - YMO - RYDEEN (72)
＜変更点＞
・コードの音色と発音タイミングの調整
・ストリングスのゲート・タイムの調整
・Bメロのリード音の音色の調整
・シーケンスの音色と音量の調整
・ドラムの音量を若干下げる
やっぱり96Khz/24bitのほうが音がいいですな。。一応判別できるわ。。
REAPERやっぱりよくできてるわ。これでたった7,000円ちゅうのはすごい。。
さらにアップデート。。
Youtube - YMO - RYDEEN (73)
微妙にドラムスの音量を上げてみた。ちょっと上げただけで全体のバランスがガラっと変わるような気がする。ちょっとコードの低域もベースと被るのでかなりカットしてみたりもしている。
Youtube - YMO - RYDEEN (74)
24bit/96KHzの音の良さを認識したら、テクノポリスも作り直したくなってきた。
Youtube - YMO - TECHNOPOLIS (12)
これはAodixというトラッカーのままなので、REAPERにデータを持ってこないといけないが。。まあ手動になるなあ。。
このカバーのベース音はちょっといけないわなあ。。作ってるときは似てると思ってるんだけど、ちょっと寝かせて再度聴くと全然違う！！ってなって自己嫌悪になるんだよなあ。。そして作り直して寝かせる。。これの繰り返し。。
RYDEENのカバーの動機となったのはこれを聴いたから。Synth-1のすごさを実感したと同時に、このソフトシンセだったらいけるかもと思ったのがもう10年以上前。。
サービス終了のお知らせ - Yahoo!ジオシティーズ
2019年3月31日をもちましてYahoo!ジオシティーズのサービス提供を終了いたしました。
ん。ちょっとまてよ。。このページgeocitiesじゃないか。。え、もうちょっとしたら消滅するんじゃないの、これ。。
それでいろいろカバーしてたらsynth-1の作者に曲紹介されてすごくうれしかったりとか。 https://t.co/9KVxWiBUdv
そういうわけで、カバー曲は音色のほぼ9割をSynth-1で作っている。。
今また原曲を聴いたが全然違うわ。やっぱり。各パートがはっきり聴こえるし、エフェクトの質が違うわな。うーん。難しい。。
いい音してるなあ。。
FM-7好きの姪bot@fm7mei
お父さんに「プログラムをしたいなー」とアピールしてNew3DSとプチコンをねだったんだけど、伯父さんが「んー、手軽だけどBASICより速いぞ」って言って、FM-7用のKコンパイラをくれたよ。
…お、おう。姪は頑張るぞい（汗 goo.gl/YJmf1C https://t.co/VhZ8zaiIDj
I-zk tom@Izk_tom
締めはこのゲーム。
よく喋るなぁ。 https://t.co/Jgx4Dv9zHN
S.F.@SFPGMR
ランタイムのデバッグを可能にするためにglsl-simulatorは作られたんだよな。cpuでglsl動かしたらそれが可能になるもんね。。
makeって軽くていいなあ。。
まずはglsl-simulatorをes6モジュール化することから始めることにする。
と思ってソースに手をつけ始めたけど、これはちょっと方向が違うよなあ。。元の路線に戻るか。。って元の路線ってなんだっけ？
要するに型変換のコストをなくしたいんだよな。。あとはglsl風の文法とプリプロセッサ、文字列対応すればいいのだよな。。
ただglsl-simulatorのコードは参考にさせていただこう。。
pratt parser ベース → peg.js ベースと来たけど、最初のバージョンの路線でいいのではという気もする。が、なんかだんだん夢が広がってきてオーバースペック気味だしそのあたり自分の身の丈に戻さんといかんよなあ。。
pegブランチを捨てる決断をせんといかん。。というような大袈裟なことではないが。所詮下手の横好きだからね。。
しかしながらオレオレ言語を作り始めてはや1年が経過しようとしている。wasmの情報もアップデートせねばいかんな。。おそらく今年は何らかの成果物を作ることができると思ってるが、甘いかもしれん。。
でもちょっとどこまで作ってどうしようとして放置したのか思い出せんな。。今年の1月の頭までは作ってたはずなのだが。。
こういう時のためにつぶやきをTogetterにまとめといたんだった。。まさに備忘録。。
オレオレ言語を作る - Togetter
node.jsでWASMを吐くコンパイラを作っています。まだ完成には至っていません。。リポジトリ
そうかあ。
・pratt parserのコードをもとに手書きパーサ＆コードジェネレータを作りかけ
・グラマーの文書化の重要性に気づき、peg.jsで文法を書き直し
・glslに立ち返り、仕様書のBNFをPEGに変換しはじめた
でしたな。。
この辺も読んどくか。
コンパイラ勉強会 まとめ #compiler_study - Togetter
2018/11/10(土) コンパイラ勉強会 @ Fixstars のまとめです。
これも読まんとな。。
ベクトル解析の本を図書館で借りたんだけどこれも全然読んでない。というか読む時間がない。。
binaryen.jsの現バージョンをちらりと見たらなんかSIMDというキーワードを見かけたけどひょっとして実装されたのかな？
これですかな。
SIMD by tlively · Pull Request #1820 · WebAssembly/binaryen · GitHub
This PR has:
Parsing and printing
Assembling and disassembling
Interpretation
C API
JS API
and their respective tests. It does not have:
Fuzzing
あかん。wasmのインストラクション半分忘れとる。。
GitHub - AssemblyScript/binaryen.js: A buildbot for binaryen.js, a port of Binaryen to the Web, with TypeScript support.
A buildbot for binaryen.js, a port of Binaryen to the Web, with TypeScript support. - AssemblyScript/binaryen.js
そうかそしてbinaryen.jsをwasmでビルドすると動かなくなってしまったんだっけ。。確か。対応しないといかんなあ。。
ビルドしなおすと確かに命令増えとるな。。SIMDですがな。。これでベクトルの演算書いたらいいかんじになるのでは。。 https://t.co/SsTEy1xBLv
前にbinaryen.jsをwasmでビルドしたときの記録はこれだ。
Promiseチェーンがどこで切れてるかをもうちょっと詳細に書いておけばよかったよ。どこで切れてたのか忘れちゃったよ。。
そこが修正されてるかどうかわからんもんな。。それとemscriptenが吐くJSはES5レベルっぽいのでちと古い。。なんかES6で吐くオプションがありそうな気がするけれど。
このSIMDインストラクション群たぶん内部でエミュレーションするんだろうなあ。このインストラクションをそのまま受けることができるブラウザは存在するのかな。 https://t.co/RuXa8JMG2C
ちなみにビルドするときはbuild.jsをこのようにしている。
compileWasm({
post: path.join(projectDirectory,"scripts" ,"binaryen.js-post.js"),
pre: path.join(projectDirectory, "scripts" ,"binaryen.js-pre.js"),
out: "binaryen-wasm.js"
});
binaryenの中身見たらエミュレーションかどうかすぐわかることだけどな。。
いずれにしろSIMDでベクトルの演算を吐くようにしとけばブラウザやnode.jsがよしなにしてくれるようになるのだろうし、利用しない手はないな。。なんかうれしいなあ。。
一応ビルドはできたんだけど、動かしてみるのはこれから。。動くかなあ。。
GitHub - sfpgmr/binaryen.js at support-binaryen-wasm-esm
A buildbot for binaryen.js, a port of Binaryen to the Web, with TypeScript support. - sfpgmr/binaryen.js
やっぱり動かんな。でも直せそうな気がする。。
どこでダメになってるのかは分かった。binaryen.jsはparseText()というメソッドがある。
Creates a module from Binaryen's s-expression text format (not official stack-style text format).
bynaryen独自のs式を渡すとモジュールバイナリを返してくれるというメソッドである。
でこれを使って、watで書いたヘルパ関数をwasmバイナリ化してJSから呼んでいるのだが、このparseText()メソッドで以下のエラーが発生していた。以前のバージョンではエラーは起こらなかった。
[parse exception: f32.reinterpret/i32]Fatal: error in parsing wasm text
ちなみにf32.reinterpret/i32というのは、i32のビット配列をそのままに型だけをf32にするというインストラクションである。これ自体は特に問題ないのだが、なぜかここでエラーが発生してしまう。
ソースはこれである。実際これをwat2wasmに食わせるとエラーなしでwasmバイナリを吐く。だがparseText()に渡すと先ほどのエラーが出るのだ。。
私が書いたS式は「official stack-style text format」で、「Binaryen's s-expression text format」じゃないからかな？と推測してるところだが、この「Binaryen's s-expression text format」って何？ちゅうのが今今の状況。。
S式って論理的・あいまいさがなく・無駄もない感じがしてちょっと好きになった。LISPが根強く残るのもよくわかる気がする。
しかし以下のS式はいけるんだよな。
(module
(export "test" (func $test))
(memory $memory 1)
(export "memory" (memory $memory))
(func $test
(drop(grow_memory (i32.const 3)))
(i32.store
(i32.const 0)
(i32.mul (current_memory) (i32.const 65536))
)
)
)
reinterpret/i32という記法がいかんのだろうか。。ちょっとbinaryenのソースを覗いてみるとするか。。
これがS式のパーサのコードっぽいな。。
ここがreinterpretインストラクションを判別してるコードなんだけどなかなか効率的ですわ。。
reiまで見ればreinterpretだと判別できるからな。。ただこのコード見ると、型を見てソースの型を判断してるようだから、reinterpret/i32の「/i32」はあってもなくてもいいような気もしないでもない。
ちょっと気になるのはreinterpret/i32と書いたときにトークナイザーがどういう処理をしてるかなんだな。
このエラーを見る限りはきちんと解釈しているようには見えるのだが。もし「/」を区切り文字として解釈してるのであれば違うエラーがでそうな気もする。。
[parse exception: f32.reinterpret/i32]Fatal: error in parsing wasm text
もうちょっとコードを読まないといかんなあ。。
ここを読んでる。
SExpressionParser::parse()
わかった。。
記法が変わったんだ。。
f32.reinterpret/i32
↓
f32.reinterpret_i32
いろいろ変わっとる。。
get_local → local.get
i64.extend_u_i32 → i64.extend_i32_u
これはwatと互換性なさそうな感じだけどこのインストラクションでwat2wasmやるとどうなるのかな。。
やってみたらエラーでたわ。。
wat2wasm ./sgl2lib2.wat
./sgl2lib2.wat:10:6: error: unexpected token "f32.reinterpret_i32", expected an instr.
(f32.reinterpret_i32
^^^^^^^^^^^^^^^^^^^
./sgl2lib2.wat:12:12: error: unexpected token local.get.
(local.get $i)
^^^^^^^^^
.
.
ちゅうことはこの一文は正しいなあ。。
parseText(text: string):
Module Creates a module from Binaryen's s-expression text format (not official stack-style text format).
masterブランチのコードは修正した。binaryen's s-expression text formatにね。。
コンパイラのエラーも消えたわ。。
https://t.co/yr0KIbHB4e
インストラクションから特殊文字を消すという提案があったのですな。。
変わっとる。。「/」が消えたのですな。。
wabtもビルドしなおすか。。
まあいずれにしろ、動かなかった原因はテキスト・フォーマットが変わったということでいいかな。。
wabtをアップデートしたら新しいインストラクションでも大丈夫だったわ。とりあえずよかった。
しかしSIMDのサポートが入ったのはちょっと大きいよな。。
ようやくというか、考え迷っていたオレオレ言語の方向性が昨日固まったので、それに従って進めていこうかなと。キーワードは「CPUとGPUコードのシームレスな統合」なんだけど。きれいに言うと。ただそれを実現することは私にとっては容易いことではない。
ちょっとスッキリした。。
S.F.@SFPGMR
wasm SIMDって今開発中のステータスなのね。。
S.F.@SFPGMR
とりあえず眠いので寝ることにしよう。おやすみなさい。。
S.F.@SFPGMR
こ、これは。。
Alon Zakaiさんのツイート: "Binaryen now has experimental wasm SIMD support, thanks to tlively https://t.co/wQwux5liE6 probably the largest PR we've ever had!"
“Binaryen now has experimental wasm SIMD support, thanks to tlively https://t.co/wQwux5liE6 probably the largest PR we've ever had!”
S.F.@SFPGMR
まとめを更新しました。相当紆余曲折してますな。。「オレオレ言語を作る」
そろそろGLSL/C++の仕様書読みを再開しようか。。
仕様書読みでなくて「オレオレ言語」作りだった。。
気がつくとC++ のドラフトも N4800に上がってるな。。日々進化し続けるC++。
draft/n4800.pdf at master · cplusplus/draft · GitHub
C++ standards drafts. Contribute to cplusplus/draft development by creating an account on GitHub.
オレオレ言語もまずは可能な限りglsl es 3.0に忠実に実装を進めようかなと。できる限りだけどね。文字列関係はC++の仕様を借りようかなあと思ったりしてる。
でももうこういうのあるんだよねえ。これをベースにしてwasm化するのがいいかもね。。
これのデモページもかなりいい感じ。。
このglsl-simulatorはglslのデバッグ目的なんだよね。確かに変数トレースやブレークやステップ実行とかできんもんな。ふつう。CPUでそれをシミュレーションすればできるわな。。
まあでもプリプロセッサを自作したいちゅう欲望が渦巻いてるので、まずはそこから再開しようかなと。今年中にできるだろうか。。
去年はコンパイラをどうやれば作れるのかが多少理解できたレベルで終わった。今年はまともなやつを作りたいよねぇ。。でもソースをコンパイルして実行できた時のうれしさは去年第一位ですよ。。
しかしまずは勉強のため、glsl-simulatorの中身を見てみようか。残念ながらレポジトリは4年前で更新が止まっている。
GitHub - burg/glsl-simulator: A simulator for OpenGL ES 1.0 Shader Language written in JavaScript.
A simulator for OpenGL ES 1.0 Shader Language written in JavaScript. - burg/glsl-simulator
とりあえずglsl-simulatorをforkした。
中身見るとES6化したくなったり、binaryen使ったりしたくなるだろうだけど、それは成り行きで。。趣味ですから。。
binaryen.jsはforkしてwasm化した。ASTのレベルでこれを使ってwasmを吐けばいいかなあと。
あとはちょっと考えてるのはAssemblyScriptを使ってコンパイラを書き直すというパターン。
AssemblyScriptって筋のいいプロジェクトだと思ってるんだよね。私。。
binaryen.jsというのは、binaryenをemsciptenでjs化したもの。
これをインフラにしてtypescript風のsyntaxを載せたのがAssemblyScriptである。
これ使って書き直せば、コンパイラ自身もwasm化できるんだよな。でまあ最終的にはセルフ・コンパイルしてAssemblyScriptから卒業するというパターンとかどうかなあとか。
とりあえずレポジトリをforkしてビルド環境を整えている途中。AssemblyScriptで書き直せるか試してみよう。ん。ちょっとまてよ。。
pegjsを使うということはpegjsが吐くコードをAssemblyScript化しないといかんよな。うわぁ。。ちゅうことはpegjsも改造が必要。。ちょっと無理かもな。。
パーサー部分を手書きすれば回避できるんだけど、どうしようかなあ。。pegjs自体をAssemblyScriptで書き直すという考えもあるけど、そうなるとそれ自体の依存モジュールをAssemblyScript化しないといけなくなるよなあ。。この筋はちょっとあきらめるか。。
結局ファイルI/Oとか考えるとJSを使わないといけないように思うから、JSをまとめ役として考えて、モジュールレベルでAssmeblyScriptの使用を検討するのがいいよなあ。。使うのなら。
binaryen.jsで直接wasmを吐く形で当面は進めるかな。。