yonatan@zozuar
Overgrown - dwitter.net/d/16088
for(i=2e3;t<9&&i--;x.fillRect(i,(T+3)*t*35,1,2e3,x.fillStyle=`hsl(95 50%${99-t*t}%`))for(T=0,j=9;j--;T=T*2/3+S((i-960*S(t*k))*k/t/99))k=2**j https://t.co/MituPl3o9P
yonatan@zozuar
mountainclouds dwitter.net/d/16195
for(a=p=i=2e3;t<9&&i--;x.fillRect(i,(a-9)*t*37,1,2e3,q=S(t**.9*.6),x.fillStyle=`hsl(200 ${75-t*t}%${60+q*50+(p-a)**.1*t}%`))for(p=a,a=j=12;j--;a+=S((i-960*S(t*k))*k/t/99)/k)k=2**j https://t.co/WPuUCMOq1s
yonatan@zozuar
dwitter.net/d/16091
for(i=2e3;t<14&&i--;f=t>1&&T<-1,z=(T+3)*t*40,r=f*(t*80-z)*2+t,x.fillRect(i,f?z:t*80,1,r,x.fillStyle=R(q=255/(1+t),q*=2.3-f,q*=1.5-f,f+.2)))for(T=0,j=9;j--;T=T/2+S((i-960*S(t*k))*k/t/99))k=2**j https://t.co/h4fjeL2h5x
S.F.@SFPGMR
習志野と東海大相模は撃ち合いとなり、習志野が力負けした感じ。やはりこういう展開になると、継投の質が明暗をわけるな。。
山内くんはランナーを出してしまうとやはり球が甘くなってしまうようだ。二死からの失点をよく見かける。抑えようとして力みが出てるのか、ランナーを気にして、投球に集中できないのか、理由はもちろんわからないが。。
あとは堀井くんだよな。力はあると思うんだけど、気負ってるのか単に力んで空回りしてるのかわからんが山内くんと同様、二死から打ち込まれることが多い気がするね。
一度試合でいいピッチングができれば
、そのあとはスッといけそうなんだけどね。。とにかく二番手の安定感が習志野の課題ですわな。。
今年は飯塚くんという今となっては大エースがいたので、山内くんが乱れてもじゅうぶんにカバーできたんだな。
飯塚くんも2年の頭くらいは、結構打ち込まれたりしてたもんな。。2018年の西地区大会では佐藤くんと古谷くんの影に隠れてたよね。しかしあの西地区大会の延長サヨナラはトラウマになるくらいの衝撃だった。ああ、もうこれで習志野はしばらく甲子園行けないなと思ってしまった。。
それが今年は春、夏と連続で出場。その間の飯塚くんの成長著しかったよね。。ここまでになるとは正直思ってなかった。。
堀井くんもまだまだ伸びしろがあるんじゃないかと思うので、春の県大会が楽しみではある。
あとは木総に頑張ってほしい。篠木くんが甲子園で投げる姿を見てみたいというのがあるよな。やっぱり千葉県代表の一角には入ってて欲しかったな。。この秋もね。。
S.F.@SFPGMR
今nodeのexpress 4.xを使ってwebを運用してるんだけど、HTTP/2を動かすのに使っているnode-spdyというモジュールがnode 11以降では動かないという問題があったんだけど、どうなったんだろうな。結局。。
SPDY fails in node >= 11.1.0 · Issue #350 · spdy-http2/node-spdy · GitHub
Hi, Couple of short investigation, why SPDY drop error message //------------------------------------------------------------------------------------------------------- buffer.js:72 class FastBuffer extends Uint8Array {} ^ RangeError: In...
でまあやむなくnode 10.xで動かしている。express 5であれば、ビルトインのhttp/2モジュールが使えるらしいからそっちに移行したいところだが、どうもexpress 5 というのはまだアルファ版らしいんだな。。
GitHub - expressjs/express at 5.0
Fast, unopinionated, minimalist web framework for node. - expressjs/express
なんかこのexpressというモジュールはnodeではかなり重要なものだと思うんだけど、なんかコミットの周期みててもそんなに活発じゃなさそうな感じがするんだな。。
そもそも静的コンテンツをserveするような用途だとexpressを使う意味はないんだけど、一部そういうところがあって、それならということで静的コンテンツ配信も一緒にまとめてしまおうというのが今のうちのサーバーの状況。コンテンツがアップデートされとらんのでどんどん腐っていってはいるが。。
もともとはnginxをフロントに使っていて、
１．静的コンテンツはnginxで配信
２．動的コンテンツはnginxをリバース・プロキシとして用い、expressにリクエストを転送
としていたんだけどね。HTTP/2の処理もnginxに任せることができたんで、２．の内部的な通信はhttpでやってたりしたんだな。
ただWebサーバーのフレームワークもいろいろあるようですな。。
The Best 10 Node.js Frameworks for 2019
A comparasion of the 10 most downloaded node.js frameworks
expressしか知らんかったけどね。。
今の状況
・express 4.xはhttp2をサポートしない
・express 5.xはhttp2をサポートしているがまだアルファ版だし、開発の動きが遅く正式バージョンがいつリリースされるか不透明
・express 4.Xではnode-spdyを使うとhttp/2のサポートは可能だがnode 11.1以降ではnode-spdyが動作しない
今の状況というか８か月くらい前の状況か。
S.F. Blog:静的サイトジェネレータのアップデート（nginx→express）
はじめに去年からWebサーバをnginxからexpressにアップデートした。途中放置気味であったがようやくまとも動くようになったので、テストを兼ねてこの記事を書くことにする。約8か月振りのブログ更新となる。静的サイト・ジェネレータ私が今使っているServers Man VPSは月額467円のエントリープラン、メモリ1GB/HDD50GBのものを使用している。最初はメモリ256MBであったがだんだ...
node-spdyの該当issueはこれかな。
なんかこれ見てる限り大したissueではないような気もするんだけどな。。
状況としては現在もあまり変わっとらんと、そういうわけですわな。。私としては、
・nodeをlatestバージョンにupdateしてexpressをhttp2で動かしたい
のだが、それは今時点ではかなわないというわけですわな。。
expressを5にしてもいいけどalphaだからなあ。。
そしてなんとなくkoa.jsに移行するというのはどうだろうかと思ってるが果たしてどうか。。もしくはnginxをフロントにするのを復活するか。。
GitHub - koajs/koa: Expressive middleware for node.js using ES2017 async functions
Expressive middleware for node.js using ES2017 async functions - koajs/koa
koa.jsはexpressの開発メンバーが開発しているらしく、こちらのほうがアクティブなように見えるな。。私は大したことしてないからkoa.jsに移行するのも簡単かもしれん。。
そういうわけでブランチ作ってexpress→koaに移行することにしてみた。
開発環境でkoa.jsを使ってhttp2で動かすことができるようになった。あとは自作のミドルウェア？を移植するだけですな。。
webhookのハンドラ、いいのがあったのでこれに差し替えるか。。
GitHub - Mr-six/koa-webhook: a koa webhook
a koa webhook. Contribute to Mr-six/koa-webhook development by creating an account on GitHub.
あとはトップページをどうするかですな。。デザインを変えたいんだよな。。
cssも機能アップしてるから、キャッチアップが大変ですわ。。
これシンプルで良さそう。
S.F.@SFPGMR
秋季関東大会
1回戦の結果
東海大相模 14-2 駿台甲府
習志野 7-3 前橋育英
青藍泰斗 6-9 西武台
常総学院 4-5 健大高崎
山梨学院 11-6 文星芸大附
花咲徳栄 11-2 拓 大 紅 陵
霞ヶ浦 2-4 桐光学園
明日の試合はこうなったか。。
センバツ出場がかかるベスト８。。
東海大相模-習志野
西武台-健大高崎
山梨学院ｰ花咲徳栄
桐光学園ｰ桐生第一
東海大相模と習志野は打ち合いになりそうな気がしないでもない。が、おそらく山内くん中一日での投球になると思うので、ちょっと分が悪い気がする。
堀井くん、山根くんの登板は今の感じではないと思うな。。あるとすれば山根くんか。。堀井くんは少しコントロールに難があるもんな。。いい投手の素質はあると思うんだけどね。。山根くんはまだまだこれからだけど、安定してる感じはする。が東海大相模の打線に対してはどうだろうね。。
まあしかし、今年の春・夏の甲子園で培ったものをこの試合で出せればいい試合になると思う。そういう経験は東海大相模もしてきているからね。経験では五分だろう。
S.F.@SFPGMR
サンダーバードのこの発進シーンは子供のころ見たときに、強烈なリアル感を感じたのを覚えている。今観るとピアノ線がよく見えるんだけど（笑）、昔のテレビ画像は粗かったから、うまく隠れてたんだろうな。。
Youtube - Thunderbirds Launches and Landings HD
S.F.@SFPGMR
Thunderbirds 1965 - Documentary
Youtube - Thunderbirds 1965 - Documentary
@YouTubeさんから
たなむ(TMS9918)@tanam1972
ファミコン以前で遊ぼう会はじまりますー
#NOZ80 https://t.co/9zHaaagKzW
S.F.@SFPGMR
お、習志野ー前橋育英始まってるな。。
https://t.co/mPt3iXZHLz
二死１，2塁で和田君凡退。。 https://t.co/wSwn0nGrJc
県大会では和田君炸裂してたけどなあ。
2回終了。山内君調子よさそう。 https://t.co/VA4xSxyZqH
前橋育英は習志野が苦手な左投手を持ってきたか。。
というより菊池君は1年生エースか！
3回終了。うーむ。これは投手戦の様相。。 https://t.co/PpQZGW8nyP
あ、表が終わっただけだった。
3回終了
習志野 ０－０ 前橋育英 https://t.co/SidnQyN9w7
前橋育英も打ちあぐねてる感あり。山内くんここまでで４K。
あ、５Kだった。
4回表 2死3塁で宮下君。
#秋季関東大会
宮下君タイムリー！
１－０
#秋季関東大会
４回表終了
習志野 １－０ 前橋育英
#秋季関東大会 https://t.co/RAvwCZcv7z
4回裏
前橋育英ノーアウト1塁で併殺。。
４回裏終了
習志野 １－０ 前橋育英
前橋育英ヒット2本打つも0点。併殺が痛い。。
#秋季関東大会 https://t.co/enDQnnBWsI
和田君このあたりでヒット一本ほしい。。
1年生エース菊池君もよく投げている。。
#秋季関東大会
ウーム。角田くん当たってるな。。できれば和田君、小澤君が塁に出てほしかったね。。
５回表終了
習志野 １－０ 前橋育英
櫻井くん繋げず。。
#秋季関東大会 https://t.co/76lvVfXef6
前橋育英も2巡目以降はいい感じになってきてる。
ヒット4本。点が欲しいところ。。
前橋育英ワンアウト、1－2塁。
犠打でツーアウト、2－3塁。習志野ピンチ。。
2死満塁
こういうとこでリリーフできないのが今の習志野の課題ですわな。。
飯塚くんはもういない。。
５回裏終了
習志野 １－２ 前橋育英
2点タイムリーで前橋育英逆転！
#秋季関東大会 https://t.co/6niLlfe3ar
やはり山内くん、ランナー背負うと制球が乱れるようですな。まあまだ2点取られただけですが。。打線に期待！
しかし1年生エースの菊池くんは要所で締めるよいピッチングをしているようで、今後に期待が持てますな。
習志野は球場整備の間に気持ちを切り替えて、普段通りの野球をすればいけると思うけどね。。
このペースだと習志野は負け試合っぽいね。。とにかく左投手に対して良い印象はない。
飴谷くんヒット。今日2安打か。。
６回表終了
習志野 １－２ 前橋育英
１塁牽制死。。
#秋季関東大会 https://t.co/cj9zAYWDMV
前橋育英ヒット。山内くんにタイミング合ってきた感じですな。。
習志野はちょっと打線がいい感じなので、逆に力みというか、粗さが出てしまってる感じがするんだな。。いつものコツコツした緻密な野球をここでやらんといかんような気がするんだけども。
６回裏終了
習志野 １－２ 前橋育英
#秋季関東大会 https://t.co/MkgbwOnUTD
7回表。小林君ヒット！
和田くん四球で一死１，２塁
小澤君ヒット。２－２。
角田くん死球。一死満塁で櫻井君。
櫻井くん、つないでくれ～。。
つないだ！！！！
４－２。１死２－３塁。
前橋育英 菊池くん。ここで習志野に捕まる。。
犠飛で習志野1点追加。５－２。
二死三塁で山内くん。。
７回表終了
習志野 ４－２ 前橋育英
でした。。
#秋季関東大会 https://t.co/rVmV1LaKHy
苦手な左投手から３点取れたのは大きいね。。
ありゃやっぱり５－２だよな。。 https://t.co/IYVVAqgSiO
moriさんのツイート: "市習志野 000 100 1← 前橋育英 000 020 7回表 習志野 8番から ○宮下君 右飛 ○小林君 中前打→失策→1死2塁ﾅｲｽﾗﾝ ○和田君 ｽﾄﾚｰﾄの四球 1死12塁 ○小澤君 左前タイムリー 2-2 尚も1死12塁… https://t.co/7bpZzAZd1j"
前橋育英1点返したか。。これで5-3。
moriさんのツイート: "市習志野 000 100 4 前橋育英 000 020 1← 6回裏 前橋育英 8番から ○代打半田君 三振 ○高橋(駿)君 空振り三振 ○皆川君 左前打 ○飯野君 右前打 2死13塁 ○諸田君 ✴️ワイルドピッチ 3-5 尚も2死2塁… https://t.co/IvrlKODWgC"
７回裏終了
習志野 ５－３ 前橋育英
#秋季関東大会 https://t.co/hpWBN4rXbT
soraさんのツイート: "前橋育英、 ピッチャー 菊池樂くん → 武藤くん 菊池くん、お疲れ様でした 習志野、8回表の攻撃 習志野 5-3 前橋育英 #関東大会"
やはり継投は左か。。
エキセントリックさんのツイート: "秋季高校野球関東大会 上毛新聞敷島球場 習志野5-3前橋育英（7回） 前橋育英8回から選手及び守備位置変更。… "
東海大相模は7回コールドか。。やはりここで勝っても次が厳しいね。。
ここで習志野、死球→犠打→ヒットで1点追加６－３。この1点は大きいね。。
８回表終了
習志野 ６－３ 前橋育英
#秋季関東大会 https://t.co/LhHZKi9LVR
このへんで習志野も継投したいところだけど、この点差ではそうもいかんなあ。。
moriさんのツイート: "市習志野 000 100 41 前橋育英 000 020 1 (8回表終了) 8回表 習志野 7番から ○飴谷君 右飛 ○宮下君 死球 ○小林君 バント 2死2塁 ○和田君 タイムリー 6-3 ○小澤君 三ゴ チェンジ ↓和田君タイムリー… https://t.co/KAkQgytpCm"
堀井くん、山根くんに期待したいところだけど。。
ちょっと外出してしまったが、７－３で習志野の勝利か。。次はあの東海大相模かあ。
次は拓大紅陵かあ。花咲徳栄にもし勝てれば、センバツに近いのはむしろ拓大紅陵のほうかもしれん。。明日の試合は竹内くんのピッチングにかかっている。。
あかん。序盤で大差がついてしまった。。
6回で9-0かあ。。しかも無安打か。。厳しいなコリャ。。
ケンゼン@Kenzen_cg
Blenderで蛇動かした！ https://t.co/sKmpOOd9l2
D.S.A.@ym2413
微妙な差ですが emu2413のリズム音と、アタックレートと、サンプリングレート変換時に意図しないローパスが掛かってた問題を修正したので比較です。v0.71が新しいバージョン。音が華やかになりすぎてるのはテーブル周り変えると直かなと期待...。 https://t.co/edECXwCFJa
と り@t0rry_
スザンヌフィギュア届いた！！！
組み立ててみたけど再現度高い！！！！ https://t.co/8Gp0Ljisej
S.F.@SFPGMR
明日は関東大会かあ。。習志野は前橋育英、拓大紅陵は花咲徳栄と。がんばれ千葉勢！
S.F.@SFPGMR
wsl2ってvhdなんで格納ディスクを移動できるんですな。。
[WSL 2] move VHD File · Issue #4320 · microsoft/WSL · GitHub
Thanks for the good work of bringing WSL 2! I am wondering that if it is possible to move VHD File to another volume. Thanks in advance!
でも注意事項として、インポートするとデフォルトユーザーの設定は引き継がれないようなので、以下で対応するといいらしい。でもまだベータ的なやつだからほかに何かあるかもしれんが。。
ということで、まずこれでvhdをワーク用のディスクに移動して、そしてwindowsのファイルシステム上にある作業用ファイルをext4にコピーしてるところ。win10からext4へのアクセスは以下のパスでアクセスできる。。
\\wsl$\(ディストリビューション)
こんな感じにwindowsからは見える。 https://t.co/RUOqwTtoBh
しかしコピーは鬼のように遅い。。
多分コピー後は快適になるはずだ❕
コピー終了。試すとやはり全然スピードが違うわ。。
これがWSL2の真の実力。。しかしもうwsl上でしかコード書いてないから、win10を使う意味が果たしてあるのだろうか。。
S.F.@SFPGMR
ロッテ、専大松戸 横山くん獲った。さすが！
S.F.@SFPGMR
wsl2ってディスクアクセス遅いなあ。。と思ってたら、このせいだったのか。
Windows10 Insider 18917 で WSL2 が来たので雑にボリュームマウントのベンチマークとってみた（追記あり) - Qiita
ext4ファイルシステムにデータを移行すれば解消するみたい。
簡単なcssのビルドも鬼のように時間がかかるのでこりゃおかしい。。と思ったんだな。。
S.F.@SFPGMR
ServersMan VPSのOSをアップグレードしようとしたら死んだので、いきおいVPS自体を引っ越すことにした。新しいサーバーはConohaにした。
sshの設定からやり直しか。。たまらんな。。面倒くさい。。
ちゅうわけでサーバー構築中。。
ブログはしばらく更新してないけど、オリジナルのはメンテがもう面倒だし、Keystoneとかにすっかなあ。。
この辺を参考にセットアップ中。iptablesの設定はがちがちにしとかんとなあ。。あとはSSHのポートも変えとかんとね。。
nodeはこの情報でインストール。入れるのはLTS。
仮レベルだがhttp/2でexpressを動かして、ウェブサーバーを復活した。。
S.F. Web
Programming,Music,Game,etc..
静的サイトジェネレータの部分をgatsby.jsで書き換えようかなと思ってるところ。。
GatsbyJS
もうちょっとモダンなサイトにしたいよなあ。。
starter のCMSサンプルがよくできてるので、ちょっと手を加えればいけそうなんだけどね。Reactは好みでないがまあ長い物に巻かれる感じですかな。。
GraphQLとやらもちょっといじってみたいし。。
と思ったが、やめとこう。CSSフレームワークを導入してデザインを変えるのと、TwitterとYoutubeのポストをまとめるコードを書くくらいに留めよう。あとやるとするとAMPのエラーを直すくらいだろうかね。トップページは作り直そうかなと思う。
ここに自分のリソース費やすと音源を作る時間が無くなってしまうもんな。。
そうでなくても忘れっぽくなってるというのに。。
うーむ。HTMLのデザイン・テンプレートをベースにごにょごにょしようかなと思うけどいろいろあるなあ。。いいなあと思っても、jqueryやbootstrapゴリゴリで、それはちょっと避けたい。できるだけ軽量ですましたいなあ。AMP対応も考慮せんといかんしなあ。。
D.S.A.@ym2413
I have updated my ym2413 emulator in C, aka emu2413. The latest version v0.70's sound drastically changed from emu2413 v0.6x which was released at 2004, widely used or ported with many emulators. github.com/digital-sound-…
S.F.@SFPGMR
今さらクォータニオンを学習中。。
あかん。難しい。今まで3次元空間での回転は軸固定でx,y,zのオイラー角で表してたのだが、回転軸ベクトルとラジアンを使って3次元の回転を表す方法をいまさら理解してさらにクォータニオンに行き着いたわけだが、朝一でこれはきつい。
回転のアニメーションをオイラー角でしていると妙な違和感があって。x,y,zを同じ角速度で回してるのになんかこう回転速度が変化するような感じになってしまうのはなんでかな。。と昔から思ってた。
voxファイルの表示
x,y,z軸固定でオイラー角でx,y,zをx,z,yの順番に回転行列を掛け合わせるのだが。各軸周りの回転が等速になってるように見えんところが気になるところだ。
Youtube - 8x8x8Voxelの表示
これはひょっとして「ジンバル・ロック」によるものなのかと考えたりとかしてたり。わからんけどね。
そこでまあ「ジンバル・ロック」のない回転とやらはどんな感じなのかと思ったわけだ。そこで思い出したのが「クォータニオン（四元数）」である。
しかし、「ジンバル・ロック」とやらはいくら頭の中で考えても全くイメージできんわけだ。これが。。
ジンバル - Wikipedia
x,y,zの各軸は互いに直交してるわけで、なんで軸が重なるねん？？となって頭が混乱するわけだ。
でまあこれを読んでみたわけだが。理解しとらんが「いいね」をつけとこう。。
こっちはクォータニオンを使うに必要な知識が書いてある。
クォータニオンはさておいて、軸ベクトルとラジアン1個で任意の回転をあらわすことができることは理解したのである。。
軸ベクトルをつかうと例えばx軸周りの回転は
(1,0,0)になるわなあ。そしてx軸かつy軸周りの回転は
(1,1,0)となるのだろうなと思う。でまあy軸だけ逆回転させたくば（1,-1,0)とすればよいのかなと。たしかに考えやすい気がするねえ。。考え方が間違って理解してなければの話だけど。。
複数のボクセルデータを表示するために今改造してるところなんだけど、これを機会にオイラー角での指定をやめて、軸ベクトル＋ラジアンで回転を表すようにしてみるつもりである。
複数のボクセルデータを表示するのはサクっと作ってしまうつもりだったんだけど、WebGL2.0の理解が深まるにつれいろいろ盛り込みたいことが増えてきてる。盛り込みたいというか変更したいというか。。
ここまでの記録をまとめた。
自作WASMプリプロセッサとWeb要素技術を使ってレトロ・シューティングを作る - Togetter
自作WASMプリプロセッサとWeb要素技術を使ってPSGエミュレータを軽く作ってみた。そしていまレトロ・シューティングを作っている（進行中）。
160x100pxへのこだわりはやはり「N-TYPE」を見てからですな。これはほんとにすごい。
Youtube - 【PC-8001】N-TYPE2【AABM2】
ようやく複数オブジェクトの表示ができるようになった。。
これがそう。なんの変哲もないポリゴンの立方体のように見えるが実はポイントスプライトで表示しているという。
ここでUBO使おうと思ったんだけど、現時点の実装では思ったほどUniformバッファの恩恵を受けられないことが分かったのでやめた。。
続いて複数キャラを同時に表示する部分を作らんといかんな。。
違うわ。複数の異なるオブジェクトだった。。
ようやく所望のものができた感じですな。。
3Dスプライトといったところか。
この粗々なピクセルの感じがレトロっぽくて好みなんだよね。。
Youtube - MagicaVoxelのデータをポイント・スプライトで表示する
オブジェクトの描画は登場キャラの頂点情報を1つのArrayBufferにまとめて、drawArraysにオフセットをあたえることでキャラの切り替えをするわけですな。
gl.drawArrays(gl.POINTS, objInfo.vindex,objInfo.count);
こうすればバッファ切り替えしなくても良くなる。でもバッファの切り替えなんてポインタの切り替えコストくらいじゃないかと思うからメリットはそんなにないかな。。
オブジェクトの情報も1つの大きなArrayBufferの１区画で管理するようにして、それをwasmから見えるようにする。wasmからそのメモリに書き込むことでキャラクターをコントロールするのですな。
512個ほどキャラを表示。混沌として何が何だか。。
Youtube - MagicaVoxelのデータ表示
現在の成果物。。Z座標に応じて輝度を暗くしてみている。フォグのかわり。。
次は入力とサウンド関係のめどをつけるか。。
DataView,ArrayBuffe,TypedArrayを使うとJSか？と思うほど型やメモリアドレスを意識したメモリアクセスができるのがすごいなあ。
仮想テキストVRAMとボクセルデータ用のスプライトバッファを1つのArrayBufferにまとめることができた。更に同じArrayBufferに入力やサウンドのI/OをマッピングすればwasmモジュールからメモリマップドI/Oで操作できるようになる。
ここまでは想定通り実装できているわけですな。
しかしWebGL2.0のシェーダーも整数値のビット演算ができるようになったから、頂点情報にフラグ情報をビット単位で詰めて渡せるようになったので頂点あたりのバイト数も節約できたわ。
ここまでをnoteにまとめた。
MagicaVoxelデータをWebGLのポイント・リスト（ポイント・スプライト）で疑似表示する｜sfpgmr｜note
mwasmのプリプロセッサをある程度完成させたところで、それ使ってゲームを作ろうとしている。wasmでゲームを作ろうと思ったら、リソースをメモリにマップしてアクセスできるようにしてやるか、JS側でリソースアクセスのための関数を作ってwasmにエクスポートする必要がある。JS側の関数を呼び出すのは安直でよいが、呼び出しのオーバーヘッドが気になるのでメモリにマップしてそこにwasmに書き込ませ、JS側でメモリをデコードして各種リソースにアクセスするようにすることにした。 内容はレトロ風の横スクロールシューティングである。パワーアップ可能な自機が敵をなぎ倒して進めるようなタイプのやつで
入力部分は過去作ったコードを若干手直しして利用することにした。自分が作ったコードにしては割とよくできてる方でよかった。。次はサウンド部分ですな。。これはJSで作った波形メモリ音源をwasm
で書き直すつもりだがさてどうなるか。
ただタッチパネルには対応してないんだな。これが。。
これが一応入力クラスのテスト画面。ふつうはキーボードでゲームパッドを刺すとそっちに切り替わる。ボタンカスタマイズもできるようにしてるけどUIでは割愛。。
https://t.co/HMQLUKpBPZ
さて、サウンド機能を実装するか。。以前JSで作った波形メモリ音源をwasm化しようかなと思ったが、PSGエミュレーション＋SCCエミュレーション＋αにしようかなと思ってる。YM2203相当のFM音源もいれてみたいと思うけどねえ。AudioWorklet+wasmでそこまでできるだろうか。。
とりあえずPSGエミュレータにSCC相当の音源を載せることからはじめるか。シーケンサー機能も併せて作ろう。これはMIDIシーケンスデータを再生する仕様にしようかね。。
以前作った波形メモリ音源はWebAudioベッタリの仕様で、ゲインノードでエンベロープ・ジェネレータを作ってたりしてた。今回はなるたけAudioworklet内で処理を完結しようと思ってるので、ほぼ作り直しになる。作り直すならSCCに近いものを...と思ったわけ。
できる限り整数（固定少数）を使ってチマチマ作るつもり。よって作業時間が相当かかりそうな気がする。
FM音源もあの出音の割には簡素なしくみだし、C/C++のソースならゴロゴロ転がってるのでそれを移植するだけで済みそうだよな。。
SCCの情報
PSG3音、SCC5音、4オペFM3音、SID3音、8ビットDA2音くらいのスペックにできれば申し分ないんだけどなあ。。私にできるだろうか。言うても先人の遺産が大量にあるので、できんことはないだろうけどね。。ほぼ全部C/C++ のソースコードあるしなあ。私はチマチマwasm
に書き換えるだけなんだけどね。。
MAMEのコードがすごいんだよなあ。
しかしなんでこんなに音源を豊富にしたいかというと、単なる趣味ですが。SPC700なんかも興味あるんだよなあ。。ゲームコンソールの中で唯一興味のある音源ですわ。。
SPC700も調べて過去にブログ記事にしてみたんだけど、なぜかAD-PCMの解説みたいになっちゃった。。
完全なエミュレーションをするのではなく、オシレータをFMか波形メモリかSIDの波形選択としてあとはフィルタとEGを作ればいいだけのような気もするな。。
結局チップに足りない機能はソフトウェアで補完して、最終的にはそのような形になるもんね。。
MAMEのソースコード久しぶりに読もうと思ってリポジトリクローンしたら結構大きいな。。
mame/src/devices/sound のソースがもう宝の山というか。「サウンドチップ・エミュレータの聖地」といっても過言ではない。。ありがたく拝読させていただこう。
やっぱりあれだよな。オシレータをPSG/SCC/SID/FMとすればいけるよなあ。コントロールI/Fはオリジナルでいこう。といってもEGのかかり方はそれぞれ（
SID/FM）だからそこをどう考えるかだな。「まんま」の音を出すつもりではなくて、いちおうオリジナル音源にするつもりだからな。
MAMEの6581（SID）ソースのオシレータ部分を見るとやっぱり波形テーブルから読みだしてピッチ変える感じになってるんだよなあ。なのでこれも波形メモリがROMの音源の一種とみることができるな。
いやしかし、SIDの設計はPSGチップとしては秀逸だと思うなあ。。
結局波形メモリにするとSCC/PSG/SIDのオシレータはカバーできるということになるな。だけどSCC/PSGとSIDはピッチの狂い方がそれぞれ異なるようだから、そこをどうするかだよなあ。ピッチは合わすようにするか。オリジナル音源だということをすぐ忘れそうになるなあ。。
ちょっとwasm用のプリプロセッサに手を加えようと思ってる。最低やらないといかんのは
・リニアメモリの利用開始オフセット指定
・構造体による相対オフセット・アドレス指定
ほんとはマクロ機能も付けたい＆記法も見直したいところだが、それはできればということで。。
プリプロセッサの機能追加は思いのほか簡単だった。とりあえずこれでいこうか。マクロ機能はどうするかなあ。久しぶりにいじってみると独自記法の部分がなんだかなあ。。って感じになっている。
メモリのオフセット定義もJSでもなくかといってS式でもなく、C風の表記になってるんだよね。ここはS式にしておけばよかったかなあと今は思ってる。
ようやく波形テーブルを指定のピッチ・ボリュームで再生するWASMを書き終えたところ。これからUIとAudioWorkletとのつなぎコードを書いて、そのあとデバッグしようと思う。EG・LFO・フィルタはそのあとだなあ。
波形テーブルはSCCに倣って8ビット×32サンプルの波形を5CH持たせている。でまあこれを指定ピッチ（Hz）で鳴らすのをどうしようかと高校野球観戦（千葉県大会）の合間に考えていた。
画面はPSGエミュレータのを少し改造して、これに波形エディットするUIを加えればいいかなあと思っている。 https://t.co/gjQ79kx24X
今週はUIを作って音を鳴らすところまでを目標とするか。。そのあとEG・LFO・フィルタを作ればまあなんとかなるだろう。
テスト用のUIを構築中。。 https://t.co/QdnXNaRgYX
ここまで作りかけてあれなのだが、設計を見直すことにした。というか昔書いた古いコードの改良で済ますことにしたといったほうがいいだろうか。古いコードというのはこれなんだけど。
2dshooting2/audio.js at master · sfpgmr/2dshooting2 · GitHub
HTML5,WebGL,WebAudioで縦スクロールシューティングゲームを作る. Contribute to sfpgmr/2dshooting2 development by creating an account on GitHub.
いろいろ考えると、AudioWorkletの中でいろいろやるのはパフォーマンス的にもまたWeb Audio APIを生かすという面でもあまり意味はないなあ。。と考えた。
オシレータ部分のみをAudioWorkletにして、そこをwasmで書く感じに変えようかなと思ったんだよね。考えはまた変わるかもしれんけどもね。。
例えばPSGのオシレータ部分だけとかね。
今得られた知見（wasmとかAudioWorklet）を使って書き直すとどうなるのかといったところ。。
とはいえ昔書いたコードもすっかり忘れているのでソースコード読んで理解しなくてはならんのだが（笑）。シーケンサ部分はモハヨナオさんのmml-parser使ってるんだよね。確か。
私が持ってるchuwiのandroid tabでPSGエミュレータを動かしてみたんだけど、やっぱりもたつく。もたつくと音がとぎれとぎれになる。何が原因かなと考えた。私のコードの書き方が悪いのかはそれは置いといて。
ひとつ思ったのはJSからwasmへのコールがやっぱり言語境界を超えるので遅いのかなと。この記事を過去に読んだからなんだけど。
Calls between JavaScript and WebAssembly are finally fast 🎉 - Mozilla Hacks - the Web developer blog
At Mozilla, we want WebAssembly to be as fast as it can be. This started with its design, which gives it great throughput. Then we improved load times with a ...
ちなみにPSGエミュレータというのはこれなんだけどね。
この記事によるとJS->wasmへの呼び出しは１億回で5500msだと書いてある。とすると１回あたり約0.055μsということになりますな。
サンプリングレートが48khzのとき、AudioWorkletが呼び出される周期は
1/48000 * 1000 * 1000 * 128 = 2666μs
となる。１サンプルあたりだと約20.8μsか。a-rateのパラメータを考えると１サンプルごとに処理しなくてはならないから0.055*128=7.04μsか。。そんなに大きな影響はないのかな。
あ、ここで自分の環境での計測ができるのか。。
あら、JStoJSとJStoWasmと関数呼び出し比較するとJsTowasm関数呼び出しのほうが２倍以上遅いみたいだな。まあ言語境界におけるオーバーヘッドがあるのはしょうがないわな。 https://t.co/Ye8j8vAqvV
ちなみにさっきのはchromeでの話で、firefoxだとJsToWasmのほうが速くなるんだな。。 https://t.co/KWBIaXfgKa
これはなんでかというと先ほどの記事に書いてあるんだな。トランポリン関数を介さずネイティブ同士で呼び出すようにして、呼び出しコストを削減してるんだよな。簡単にいうと。。
ようし、これからはFirefoxでいこう！と言いたいところだが、AudioWorkletはFirefoxではサポートしてないんだな。これが。。
ただ96KHzのサンプリングレート、2.6ms以内で音声処理すべてをこなそうとするのはJS/WASMでは難しいかもしれんね。別スレッドで先行処理してバッファリングしておいて、AudioWorklet内ではバッファコピー位に留めておくくらいが現実的なのかもね。。
このようなことは別の手段でもできるから、このアイデアもあまりAudioWorkletをうまく使っているとは言えんねぇ。。
違うな。96khzだと1.3msか。。128サンプル単位だと。。
もしWASMを使うなら、AudioWorklet使うならJSでバッファコピーだけするようにして、別にタイマーかワーカーかで５０ms単位くらいの大きい括りで処理するのがよいかもね。
これもちょっと試してみるか。。
メインスレッドのタイマー処理でオーディオをレンダリングしてバッファ（おそらくリングバッファ）に溜め込んでおいて、AudioWorkletがそのバッファを128byteずつ読み込んで処理することを考えている。
気になっているのが不要なメモリコピー。ワーカー間のデータのやり取りはpostMessageでやるんだけどその時にメモリのコピーが発生するんだよな。なのでAudioWorklet側とメモリを共有したいという欲求が出てくるんだよね。
こういう時のためにどうもSharedMemoryBufferちゅうのが用意されとるらしいのだが、ただMDNを見ると「Spectre対応のために無効化した」と書いてあるんだな。。 https://t.co/vivLDeTdf4
別の情報では復活したようなことも書いてあるんだけどもね。。
The Return of SharedArrayBuffers and Atomics - Blog | SitePen
A common complaint of modern web apps is the concept of jank; web pages being unresponsive to user input and frame rates being low. Left unmitigated, this problem leads to a poor quality experience for end users of our web applications.
現状のブラウザサポート状況は惨憺たるものですな。Chromeだけのようだ。今は。。
https://t.co/DOrFhsodDa
まあしかし、AudioWorklet使ってる時点でChromeしか動かんのだが（笑）。近々にはEdgeでも動くようになると思うけどね。Chromeとべースは同じになるからね。。
SharedArrayBuffer使ってやってみますか。一度。
「所有権の譲渡 (Transferable Objects) によるデータの引き渡し」ちゅうのもあるのかな？
Web Worker の使用 - Web API | MDN
Web Worker は、ウェブコンテンツがスクリプトをバックグラウンドのスレッドで実行するためのシンプルな手段です。 Worker スレッドは、ユーザーインターフェイスを妨げることなくタスクを実行できます。加えて、それらは (responseXML 属性や channel 属性は常に null ですが) XMLHttpRequest を使用して入出力を行うこともできます。生成された Worker は、生成元が指定したイベントハンドラーへメッセージを送ることにより JavaScript コードへメッセージを送ることができます (その逆も可能です)。本記事では、 Web Workers の使い方を詳しく紹介します。
しかしこれ使うと、所有権がワーカーに移るんだな。ということはオーディオをバッファにレンダリングするたびにnew ArrayBuffer()しなければならなくなるちゅうことですわ。そのコストも結構高い気がする。やっぱりSharedArrayBufferだよなあ。。
そういえば、WebAudioってオフラインレンダリングできるんじゃなかったっけ？
GPUでオフライン処理するっちゅう手もあるわなあ。。だんだんWASMから離れていってるけど。
具体的にいうとtransform feedbackを使うということだけどね。
サンプルで理解するWebGL 2.0 - Transform Feedbackによるパーティクル表現 - ICS MEDIA
ブラウザからハードウェアアクセラレーションを使用してリッチな表現を実現できるWebGL。その新たなバージョンであるWebGL 2.0はChromeとFirefoxで標準で利用でき、次世代のウェブ3D表現技術として注目されています。 前回の記事では一度のドローコール（描画命令）で複数のテクスチャーに別々の情報を同時に描画（出力）できるMultiple Render Targets（マルチプル・レンダー・ターゲッツ）について紹介しました。
しかしこれもGPU <-> CPU間のデータの受け渡しで時間がかかるのではないかなということ。あとはコールのコストがあるのでできれば大きいまとまりで処理すべきかなと。
WebAudioのAudioWorkletでは128サンプル単位の処理となるから、サンプリングレートを考慮しながらバッファサイズを求めてそれを共有することになるだろうね。
wasmでやるならFixed Width SIMDが使えるようになるとうれしいのだが。
SIMD can speed up applications that process lots of data that is naturally organized as 2, 3, or 4 element vectors. SIMD is also useful when compiling native code to WebAssembly.
主要ブラウザは「実装中」のステータスですな。
ちなみにこれはWebAudio + JSの波形メモリ音源。昔作ったやつに手をちょっとだけ加えた。
Youtube - WebAudioで波形メモリ音源を作る
ちなみにこれだとAndroid Tabでも再生にモタリはほぼない。
フィルタはないし、音量のEGだけでピッチEGもないからそりゃまあそうかなあ。。といった感じだ。
AudioWorkletってhttpsで配信されんと動かんのね。localhostは例外的にhttpが利用可能とのこと。wsl -> wsl2に移行して気づいた。wsl2だと仮想マシンのIPがつくのでlocalhost(127.0.0.1)ではテストできんのよね。
それでAudioContext.audioWorklet.addModuleでエラー。httpだとAudioContext.audioWorkletプロパティ自体が存在しなくなるんだな。
一つのアプローチとして、
1. web workerの中でwasmを動かして、メモリにレンダリング
2. メインスレッドがメモリをAudioWorkletに渡す
3. AudioWorkletがメモリを128サンプルずつ処理
を試そうとしてる。この間を取り持つのをSharedArrayBufferに担ってもらおうと思った。
メモリ転送コストというか、コピーのコストは極力減らした形で処理したいと思ったんだな。しかし考えるとWebAssembly.Memoryで作るメモリはSharedArrayBufferにはなれないんですな。現状。
だからWASMのメモリからSharedArrayBufferへのメモリコピーが発生するんですな。それで過去こんなproposalがあったのですな。。
allow Memory.buffer to be a SharedArrayBuffer · Issue #950 · WebAssembly/design · GitHub
Some background: I'm working on Browsix, a tool for running multiple C, C++, Go and node.js programs as processes in the browser. We do this for C programs by compiling with a (fork) of Emscripten and running the compiled "binary" in a W...
この話はその後wasmのthreadsで議論されて、最終的には
let memory = new WebAssembly.Memory({initial: 1, maximum: 1, shared: true});
「shared」を「true」とすることでSharedArrayBufferになることができるようだ。
threadsの仕様も読んどこう。
threads/SharedArrayBufferはchromeではflagで使えるようにはできるみたいだな。 https://t.co/ruu1Rp4Z0s
ちょっと試してみようか。SharedArrayBufferはspectre問題で一度すべてのブラウザでdisableにされ、chrome以外のブラウザはまだ使えるようにはなってないようだが、そこの理由も知りたいところだが。
なかなか重い議論っぽいね。。このあたり。
SharedArrayBuffer and timing attacks (Meltdown and Spectre) · Issue #3 · tc39/security · GitHub
I think everyone was aware that ShareArrayBuffer allows for creating accurate timers. With the recent release of Meltdown and Spectre, SharedArrayBuffer was disabled in all browsers.
そもそもspectreとかの話って何が問題なのかよくわかってないよなあ。私は。。過去記事をちゃんと読んどくか。そして現状その問題はどうなっているのかだよな。。
chromeがSharedArrayBufferを再度有効化したのはSite Isorationしたからなのか。。
Spectre/Meltdownとその派生
SCAIS 2019 (Small-workshop on Communications between Academia and Industry for Security) https://researchmap.jp/sug/SCAIS2019/ の発表資料
CPUのアーキテクチャを追っかけてたのはスーパースケーラとかというワードが目新しいころ。Penitum登場のころくらいまで。分岐予測とかね。今は3次キャッシュ、投機的実行、マルチコア、SIMDとかまあてんこ盛りでまったくついていけてないわ。。
キャッシュにのると実行時間が短縮されるから、それを高精度タイマーで計測して値を特定するということなのかね？なんかすごい話だな。
いやそういう話でもないのか。これ読んだけど全く理解できん。なんでこれで任意のメモリを読むことができるのか。。
図解でわかるSpectreとMeltdown - Speaker Deck
まあこれくらいの理解でいいか。。
ブラウザベンダーのSpectre and Meltdown対応 - abcdefGets
Spectre and Meltdownについては前回書いたが、 各ブラウザベンダーがとっている対応について今回は書く。 といっても大したことではないのだが。 対応一覧 Google Chrome SharedArrayBufferのデフォルト無効化とPerformance.nowの解像度を下げる（どこまでかは不明） Per Site Isolationを有効化 Firefox SharedArrayBufferのデフォルト無効化とPerformance.nowの解像度を20μsまで下げる Safari SharedArrayBufferのデフォルト無効化とPerformance.nowの解像…
いろいろ調べて、ここに行き着いている。
As with SharedArrayBuffers in JavaScript, this allows very fast communication between the Workers. This can be used to offload computation to another thread to keep the main thread and its UI responsive.
Chrome 74以降、WebAssemblyのスレッドサポートが既定で有効化されているんだな。ということはMemoryのオプションsharedが使えるということだよね。
ということはWebAssemblyのメモリをshared=trueで作成すると、そのベースとなるbufferは共有利用できる状態になる。つまりSharedArrayBufferになるというわけですわな。
threadサポートと言っても、別にwasmにスレッドコントロールができるわけではなくて、スレッドで問題となるメモリアクセス競合を回避するための命令が追加されるだけなんだよな。
つまり、WebAssembly.Memoryをshared=trueで作成すれば、メインスレッド、worker、AudioWorklet間でメモリコピーが発生することなくデータのやり取りができるようになるということなんだな。
スレッドにおけるメモリアクセス競合の回避手法についてはそりゃもうC/C++の世界では語りつくされた感があるよね。そのあたりを多少知ってると理解しやすいよね。
ちょっとそれるけど、chrome 75だとメモリのバルク・コピー命令も実装されたようだね。
メモリ共有の恩恵を受けるのは大きいサイズの場合であって、小さい場合はコピーとそう変わらないんじゃないかという気もする。メモリ共有自体コストがかかる処理だもんね。。
さて高校野球チェックの合間にちょこちょこ実装してくとするか。。
ちょっと前に作ったPSGエミュレータのコードを少し改造してメインスレッドで作成したWebAssembly.MemoryをAudioWorklet上のwasmモジュールと共有できるか試してみた。
見た目は何も変わらないけどね。chromeはもうすでにwasmのthreadsサポートが既定で動くようになっていた。wasm側はメモリをimportして共有するように修正した。
https://t.co/tIhrsb3bYM
(export "memory" (memory $memory))
↓
(import "env" "memory" (memory $memory 1 1 shared))
wasm側は「shared」を入れ、wat2wasmで--enable-threadsをつけてwasm化する。私はwabt.js使ってるけどね。気を付けなればいけないのはメモリについては最大サイズ指定がsharedの時はmustだってこと。
メインスレッド側のメモリは「shared」オプションをつけて作成する。
const memory = new WebAssembly.Memory({initial:1,shared:true,maximum:1});
maximum指定をしないとエラーになる。SharedArrayBufferが内部で使われるようだね。
#webassembly
このメモリはpostMessageで送っても参照のみのコピーとなって、メインスレッドとオーディオ・ワークレットでインスタンス化したwasmと共有できるようになる。
#WebAssembly
とりあえずできることが分かったので、psgエミュレータを別のワーカーで動かすようにして、メインスレッド・AudioWorklet・ワーカー間で協調動作するようにコードを変えてみる。
wabt.jsはドキュメント上には書いていないけれど、3つ目の引数としてfeaturesオプションがあって、ここで--enable-xxxxxを設定することができる。
wabt.parseWat(path,watText,features);
例えば--enable-threadsをしたくば
features.threads = true
みたくする。
wabt.jsのこの辺りのコードを読んで知った。
今回はリングバッファにして、できる限りメモリをロックせず動かそうかなと思う。。
昔と違ってマルチコアになってるので、それなりにスレッド使わないともったいないよね。。スレッドがコア別に分けられるかはよくわからんけどね。。
１９８０年代後半のアーケード基板はオーディオ用にサブCPUを載せてたりしたから、それに倣う感じ。
実装スピードは夏バテもありものすごく落ちている。超絶ノロノロ状態だが、一日数行でもコードを書いてるのでいつかはできるだろう。。
仕事から帰るとヘトヘトで何もしたくなくなるんだよなあ。。この時期。
ようやく実装を終え、デバッグのステータスに入った。
まだまともに動いてないのでなんなのだが、SharedArrayBufferは、webAssembly,web-worker,AudioWorklet,webgl,メインスレッド間で共有できることを理解した。
メインスレッドでWebAssembly.Memoryをshared=trueで作ると、そのメモリはコピーコストを伴わずwasm/webgl/worker/audioWorklet間で共有できる。これができるのは今のところchromeだけのようだけど。
共有メモリにはオペレーションの原子性を保証するメソッド群がAtomicsに定義されている。
このようなことがJSでできるようになってることはすごいことだね。今更だけど。
webAssemblyのステップトレースができるchromeもすごい。これがあるのでwatでコーディングするモチベーションを保つことができる。 https://t.co/YiEnMvTfSn
ウーム。問題発生。今やろうとしてるのは、
１．worker中のwasmでオーディオをレンダリング
２．AudioWorkletでレンダリングしたオーディオデータを再生
で、このデータを受け渡しをSharedArrayBufferでやろうとしてる。
もう少し細かくいうと
１．メインスレッドでWebAssembly.Memoryを共有モードで作成
２．そのメモリをpostMessageでworkerとAudioWorkletに渡す
ことでメモリを共有して、そのメモリにデータをロード・ストアしてスレッド間のデータ受け渡しをしようとしてる。
私はWebAssembly.Memoryを共有モード(shared :true)で作れば、postMessageで送っても内部的に作成されるSharedArrayBufferはクローンされずポインタのみ渡されると期待していたがそうではなかった。。クローンされてるようだ。どうもSharedArrayBufferそのものをpostMessageせんといかんようだ。
WebAssembly.Memoryを生成するときにShareArrayBufferを指定できればよいのだけれど、それはないので、ちょっと工夫しなければならないね。
WebAsssembly.MemoryにはbufferプロパティがあるのでこれをpostMessageすればよさそうだけど、そうするとworker側のwasmでメモリをインポートすることができんようになってしまうんだな。これが。
となると、
１．メインスレッド側は必要なメモリページ数を計算
２．workerへ必要メモリページ数をpostMessage
３．worker側でWebAssembly.Memoryを作成。メインスレッドへ内部SharedArrayBufferへの参照を返す。
４．メインスレッドはその参照をAudioWorkletにpostMessage
みたいにすればいいかな？
しかし現状のレベルではWebAssembly.Memory自体をスレッド間(worker/メインスレッド）で共有できんのですな。これはちと痛いですな。。
しかしこのサンプルを見ると、WebAssembly.Memoryはスレッド間で共有できてる風なんだけどなあ。ひょっとして何か凡ミスしてるかもしれん。。
https://t.co/WxuGvcjpGS
まあこのコード見たから「いける！」と思ったんだった。そういえば。。
どうも私の凡ミスっぽい。WebAssembly.Memoryはshared=trueにすればスレッド間で共有できるのは間違いないようだ。そりゃそうか。。
私のwasm関数がおかしな動きしてるだけというオチ。
とりあえずメモリが共有できてることだけは確認できた。が、まだ動いてない。。しょうもないバグだった。しかしまあ、サンドボックス環境（安全性がそこそこ担保された環境）でリニアメモリを各スレッド間で共有して自由にアクセスできるのはちょっとうれしいね。
PSGエミュレータのworker改造版が動けば、いよいよオリジナル？の波形メモリ音源をWebAssemblyベースで作って先に進めるとしよう。。
うーむ。音が鳴らんなあ。。
Bugを追い込んでるが、凡ミス部分がなかなか発見できん。。いうても1日１時間もいじってないけど。。モチベーション低下中。。
なんかこう、workerのデバッグってやりにくいなあ。。
いやぁ。ようやく音が鳴るようになったなあ。workerの中で25msのsetTimeoutだとタイマーの間隔が短すぎるようだ。100msくらいにしないとまともに音が鳴らないわ。。
と思ったけどBugを見つけた。25msくらいでも行けるようになったなあ。。
現状の成果物はこんな感じ。
Youtube - WebWorker+AudioWorklet+WebAssemblyでPSGをエミュレーションする
これが一応私の環境で動いてるやつ。。
Chromeしか動きませんが。。
えらい時間がかかってしまったなあ。。
しかしこれで技術的なめどはついたので、いよいよ波形メモリ音源をwasmで作るとするか。。バグを潰してる間もどうしようかいろいろ考えたんだよねえ。。
波形メモリ＋EG＋フィルタだよな。やっぱり。ちゅうことでSCC+SIDみたいなやつでいこうかなと。とりあえずそれで設計しつつ実装すると。
あとはシーケンサかあ。MML書けるようにするかそれともStandard MIDIをそのまま再生できるようにするか。。。
私REAPERというDAWを使ってるので、JS Pluginで同じ仕様の音源を作って、REAPERで作曲してそのデータを再生するようにしようかなとも思ってる。
そういえば思い出したのが、WebAudio APIを使ってモジュラータイプのやつを途中までつくってたんだっけ。。ステップシーケンサー作ってる途中でやる気なくしたんだよな。
https://t.co/0qxAPewFLs
レコポっぽいシーケンス・エディタを志向しててそれなりにできてた気もするけどなあ。。 https://t.co/kxJeodX2IX
これ改造してエディタ＋シーケンサを作れんかな。。
まあでもあれかあ、REAPERでやってみるかあ。。
前作って放置したWebAudioのやつを動画にしてみた。エディタはレコポのコマンドのまんまにしようとしてたみたいね。。
Youtube - Web Audio Moduler
これはなかなかいいね。。
GitHub - a1k0n/jsxm: FastTracker 2 .xm module player in Javascript
FastTracker 2 .xm module player in Javascript. Contribute to a1k0n/jsxm development by creating an account on GitHub.
おぉ。これはFastTracker IIのクローンか。。
うーむ。。。いいね。。
WebSid - the first HTML5/JavaScript C64 music player
WebSid is a C64 emulator that allows to play original binary music files directly within the browser.
SID界隈のソースをじっくり読もうかのう。。
帰省中も少し音源のことを考えた結果、音源作る前にシーケンサーのコードをwasmで書こうかなと思った。それでPSGを演奏してみようかなと。MMLっぽい言語のパーサもついでにpegで書いて、それをメモリに落とすコンパイラを作り、シーケンサーに渡して演奏させるようにするつもり。
と思ったがやっぱりまずは波形メモリ音源を先に作ろうと思う。。どっちやねん。。
そういうわけで先ずはEGから作り始めている。。
コツコツmwasm(自作プリプロセッサ)でEQを実装中。もうちょっとでできる。
だいぶwatでの実装も慣れてきた感じ。S式ってシンプルでいいなあ。。 https://t.co/JbmXjRRuul
EQじゃなくてEGだった。。
EGを作る
↓
WaveTable部分を作る
↓
一度音を鳴らしてみる
↓
LFOを作る
↓
フィルタを作る
の順番で作っていくつもり。AudioWorklet+Workerで処理が間に合うかはよくわからんね。。
とりあえずEG出来た。。
さて次は波形テーブル部分を作るとしますかな。
実のところEnvelope Genetator（EG）もADSRのそれぞれのフェーズへの移行を直線的、つまり一次関数で実装する分には楽なのだが、アナログ・シンセのEGをまねるとなると結構面倒くさくてですな。。
VSTiの作り方 - 7.おまけ (ADSRの実装) | g200kg Music & Software
私のEGはもれなくいい加減なやつなんですな。つまり直線的なやつですわ。
波形メモリもなんちゅうか、エイリアシングノイズが発生するという問題があるので、それをできるだけ抑えてきれいな波形を出すとなると周波数帯域に応じた複数の波形データを用意する必要があったりして、凝りだすと止まらんわけですな。マルチ・サンプルとか言ったりもしますわな。。
しかしそれは楽器としての話で、例えば古いサウンド・チップなんかはコストがかかる話なので、エイリアシング・ノイズは承知の上で割り切ったりしてるんですな。例えばSCCなんかは８ビット×32サンプルで発声可能なすべての音域をカバーするもんね。
ということで我々はシステムに起因するノイズが含まれた音を聞くことになるのだけど、そのノイズが聴感上耳障りなのかどうかというのはまた別の話なんですな。そこに独特の味や良さを感じるひとたちもいるわけで。
SCC・PSGはさらにピッチ・コントロールに制約があるのでちょっと音痴になったりするんだけど、それに違和感を感じる人もいれば、感じない人もいるわけで。
波形メモリというのはオシレータの一種なわけで。オシレータもいろいろな作り方があるんだよな。例えば計算によってサイン波・矩形波・のこぎり波などの周期波形を出力する方法もある。
リアルタイムに計算によって波形出力するのは昔はコストが高かったので、あらかじめメモリに波形情報を保存しておいて、それを読み出すことによって波形合成する方式がまず普及したんですな。
BLITなんかも昔調べたよなあ。。
サンプリング周波数変換なんかも結構奥が深くてですな。やっぱりノイズを含む問題があって、それを抑えるためのテクニックがあるんですわ。
サンプリング周波数変換だけで一冊の本になってしまうくらいですからな。。
ちょっと内部的なサンプリングレートを24KHz固定にしようかなぁと考えててね。いまどきのPCはオーディオのサンプリングレートは可変で、それに合わせて内部処理してもいいんだけど、高周波数になるとちょっと処理的にきつそうだし、Lo-Fiな音で十分だという気持ちもある。
そうはいってもPCの方は再生サンプリング周波数は可変だから、もし内部の周波数を固定にするとレート変換をやらなくてはいけなくなるんだな。でも私のPCだと96KHzくらいでも処理できたりできてるけどね。。さて、どうするか。。
WaveTableの実装はとりあえず終わり。これからテストに入る。。
テスト用の音源＆UIを作って鳴らしてみる。
このwasmのデバッガはありがたい。スタックやメモリの内容、ローカル変数の値が見れるしね。S式でソースを書いてるのでフラットモードを追うのはちと面倒だけど。。 https://t.co/QNW2PlC26Y
wasmで書いた波形メモリのオシレータはようやく動くようになった。
波形メモリ音源の体裁を整える作業を実施中。コンピュータはメモリへのロード・ストアがいかに多いかがwasmを直接書いてみると実感できる。しかもS式で書きなれてきて、スタックが今どんな状態か頭で想像できるようになってきたわ。
平行してデジタル・フィルタのコードを物色中。とりあえずはMAMEのSIDのコードを参考にwasmで書こうかなと思っているけど、やっぱりフィルタは重い処理だね。。
Worker自体で処理するよりは、コードをGLSLで書いてGPUにさせたほうがいいかもしれんな。まあ書いてみんとわからんけど。
RolandのVSCも最初はフィルタなしだったもんなあ。。
波形メモリシンセとして動くコードをwasmで書いてるが、call_indiectの書き方でハマり中。。wabt.jsからよくわからないエラーが出てコンパイルできんのですわ。。
仕様だけで書き方がわからない時は、wasmのテストコードを読んだりしてる。。
(table funcref
...
ん、funcref ? なんだこれ。
これか。。
anyfunc から funcrefに変わっとるのね。。
仕様もそうなっとるな。。
それはそれとして、元々の問題は凡ミスだった。。
波形メモリ音源の実装のめどがつきそうな感じになってきたな。。音が鳴ったらフィルタを作って終わりにしよう。演奏部分（シーケンサ）も作らんといかんしな。。年内にゲームシステムが完成するか微妙になってきたね。もう9月だもんね。。
ゲーム・システムが完成したらようやくゲームつくりに入れるからなあ。。
プログラミングにかける時間は平日は多くて１時間、休日は２－３時間くらいだからなかなか進まんよなあ。。それくらいしか集中力が続かんのよねぇ。。
もちろん趣味のプログラミングに割く時間だけだけどね。。
ぼちぼちテスト＆バグつぶしをやってる。あれれ、memory.grow でエラー出るなあ。。 https://t.co/rFhbOcuVBc
うーむ。JS側でgrowしてもアウトですな。。 https://t.co/b98pbNl8Cr
shared arraybufferだとダメなのかな。。。
普通のmemoryだといけるな。。やっぱりsharedだとmemory.growできん仕様なのかな。。 https://t.co/F5xHT3nT1g
これはちょっと行き詰った感ありですな。。
しかしまあ特別shared memoryだからといってmemory.growがfailするとは書いてないからなあ。。
「grow_memory of a shared linear memory is allowed.」だもんねぇ・・。
どうもこのBugっぽいねぇ。。
このBugはまだ解消されてない模様。というかIssue9380のためにブロックされているようだ。
ちょっと待ちかあ。初期アロケートメモリを大きくしてテストを続けるかな。。
そういえばガベコレも動かせるようになったんだよな。。 https://t.co/KIowNFTnbx
おっと、自作プリプロセッサのバグを発見。修正せねばいかんな。。
プリプロセッサのバグを取り終え、波形メモリ音源プロトタイプのテスト＆バグつぶしを再開。まだちゃんと動いてはいない。。
プリプロセッサもS式を崩さないように構文設計すればよかったかなあと思ったりするな。。
今のところ、フィルタなし、波形メモリによるオシレータ、ピッチLFO/EG、アンプLFO/EGという構成になってる。
WSGやSCCの時代はチップとソフトウェアでこれくらいのスペックを実現してると思う。。
MOD界隈でもなかなかデジタルフィルタをソフトウェアかつリアルタイムで動かすことはできなかった。そこは長い間DSPが担う部分だったんだよな。。
とりあえず実行すると何らかの波形出力が得られるようになった。これからUIと簡易シーケンサを作って実際に鳴らしてみるとするか。。
PSGエミュレータに比べてパラメータが圧倒的に増えたんでちょっと面倒なんだよねえ。。
先にフィルタを実装してみることにした。。
このコードを参考にして。。
簡単なデジタルフィルタのサンプルコード | C++でVST作り
簡単なデジタルフィルタの実装についてで説明したフィルタのサンプルコードです。 「Z変換」や「伝達関数」といった高度な数学を極力使わずに実装するフィルタのサンプルコードです。 「簡単なデジタルフィルタの実装について」も合わせてお読みください。
フィルタ実装は今半分くらい進んでいる。サンプルコードがすごくわかりやすくてbiquadフィルタの理解も少しは高まった気がしないでもない。しかし原理の理解は浅い。。
離散数値で構成されるデジタルの音の世界では、ある「一定期間の音声データの平均をとること」≒「ローパスフィルタをかける」ことということは感覚的に理解している。
がそれ以上はよくわからない。よくわからないがしかしフィルタのコード自体はいたって簡単である。がしかしなぜこれでLPFやHPFになったりするのかがよくわからんのであった。。
v8では--wasm-math-intrinsicsが使えるのであった。。これでsin/cosの呼び出しコストが抑えられるのでjsのMathを利用することにした。新たにsin/cosを作るのはとりあえずやめておこう。
下のサンプルコードをwasmに書き換えた。このフィルタを使えるように波形メモリシンセの修正にこれから入ろうと思う。その前に耳鼻科に行かんとね。。
うーむ。思ったほど進捗できず。。
まあしかし少しずつでも進めればいつかはできるからね。。
ようやく音が鳴り、UI作りに入る。UIができたら各パラメータをいじって所望の動きになっているかテストする。 https://t.co/6EARekLIJd
まだしかし音源としては機能が足りてないので、そこは追加実装しなくてはならない。さて、この音源使い物にはたしてなるのか。。
まず、波形テーブルの編集部分から作り始めるとするか。。
そういうことで作成中。数式で波形を生成する機能+ハンド・ドローイングで波形をエディットすることにしてみた。 https://t.co/qHxEAfX5h3
波形メモリのサンプル数が512だとやっぱり綺麗だな。。 https://t.co/38VKWy2ChD
サンプル数が16だとレトロな感じ。。 https://t.co/85BrpIejqi
これを波形メモリに直接反映して結果をすぐ確認できるようにするつもり。波形メモリは共有メモリに格納してるのでこの辺は簡単かと。。
式で波形生成できるようにしてみたがこれが結構面白くてちょっとハマってる。。
FM変調風 https://t.co/O1EwWWh3ni
フーリエ級数による矩形波。ギブス現象が出とる。。 https://t.co/I6lfmzOsen
級数の数を増やすとほほほぼ矩形波になるな。。 https://t.co/8BhpQJeG9p
矩形波はこんな式でもいけるけどね。。 https://t.co/DbBAkxdWzu
鋸波 https://t.co/saMexy7ELA
三角波 https://t.co/zqRhaIphHW
フーリエ級数による鋸波
やはり項が有限だとギブス現象が出ますな。。 https://t.co/nHI34guVx6
多分正弦波の和ですべての波形は表現できるんだろうなあ。フーリエさんちゅうのはすごいですなあ。。
FMは簡単な実装で複雑な波形を作ることができる。しかもEGだけでフィルタを使わずに含まれる周波数の成分を変えることができるという。
原理は簡単なんでチップも安価に作ることができるし、PSGに比べてその音色の豊かさは比較にならない。しかも従来のシンセでは出ない音も出すことができたという。。
FM音源を開発したヤマハ社にはリスペクトしかないですな。おかげでゲーム音楽がリッチになったもんな。。
波形エディタがようやく動くようになったので動画にしてみた。
Youtube - 波形メモリ音源の制作ー波形メモリエディタ
WebAssembly.MemoryのbufferがSharedArrayBufferのときgrowできんというBugどうやらFixした模様ですな。。
これがいつChromeに反映されるかだが。
波形メモリの編集部分がそこそこできたので、音色(Timbre)エディタ部分を作ろうかなと思う。EGやフィルタ・パラメータをいじる部分。
音色エディタを作成中。ようやく音量のEGとLFOがエディットできるようになった。
Youtube - 波形メモリ音源の制作ー音色エディタ
年内に所望のゲーム・システムはできるだろうか。やばくなってきたな。。その上に載るゲームのアイデアもモヤっとしとるがな。。
フィルタのUI作成中。ああ、面倒くさい。。 https://t.co/nzhIOhNolg
とりあえずフィルタのパラメータいじるとこまでUIコードを書いたがうんともすんともいわない状態。。
ようやくフィルタが動くようになった。まだなおさないといけないところはある。。
Youtube - 波形メモリ音源の制作ーフィルタの実装
これが終わったらピッチのテストか。。これでようやく波形メモリシンセとしては完成か。。次は演奏部分（シーケンサ）を作らなくてはいけないな。過去何度も演奏エンジンだけで作ってエディタで挫折してるので、なんとか乗り越えたいところ。。今回はpegで演奏用の言語（MMLではない）を作ろうかなと。
今回作ってて面白いなと思ったのは、式からの波形生成。以下のような式を作って波形を作ると、鋸波と正弦波が半分ずつミックスされて聞こえるところ。式から聞こえる音がなんとなく想像できるのが楽しいなと。当たり前の話だけどね。。
Math.sin(t * Math.PI) * 0.5 + t * 0.5
ちなみにtは0-1の間で変化する。。
まだ単音でしか鳴らせてないので、これが８音ポリくらいになったときに処理負荷がどれくらいになるのか想像がつかんので、やってみるしかないんだけど、そこがちょっと不安かなと。あ、そういえばマルチ・ティンバーで鳴るようにするコードも書かんといかん。
あとサンプラ機能もな。。
ピッチ部分のUIも作ったが、見事にBugっている。ピッチEGいじってるうちにパックマンがやられた時のような音が出た。。
Youtube - 波形メモリシンセの作成 - Pitch UIの作成
波形はこんな感じで、正弦波を加算合成して作ったのですわ。。
(Math.sin(t * Math.PI) + Math.sin(2 * t * Math.PI) + Math.sin(4 * t * Math.PI)) / 3 https://t.co/aZi53CdbtE
ピッチの算出式はそもそも間違ってるようなので見直さんといかんな。。
算出式は間違ってなかったけど、アルゴリズムが間違っていたな。。ピッチの計算は誤差の蓄積やら桁あふれやらデノーマルやらを考えるとf32ではなくu64の固定小数点で計算したほうがよさそうだな。。それでやってみるか。。
f32のままでやってもいいけど小数点以下の桁数を抑えてデノーマルを防ぐようにするという手もあるかなぁ。でも結局波形テーブル引きするときに整数化するからなあ。。
64bit幅、小数部16bitの固定小数点で波形メモリのピッチを計算しなおすことにして実装中。固定小数点の乗算・除算のコツをすっかり忘れてしまってた。オーバーフローとか乗算後のシフトとか、除算前のシフトとかをね。。
これまでの成果。LFOとかピッチがちょっとおかしい。。
Youtube - 波形メモリ音源の作成-20191004
フィルタ使えると管楽器的な音がリアルになるよなあ。やっぱり。時間的な周波数成分の変化は音色にとって重要だなということがわかる。
chromeでWASMのSIMDが試験的に実装されたので、それをいつどこで使うかだよなあ。まあもうちょっとちゃんと動くようになってから考えるか。
いちおうオシレータの部分は他の波形生成方式に差し替えできるように作ってるので、音源として完成したらFM方式のオシレータも作ってみたいんだよな。。AFM音源みたいなやつ。。
それよりもゲーム作りを進める方が先か。。
あ、それとフィルタのQが全然効いてないのだった。。
まあしかし、この部分はほんとはAudioWorkletでなく、oscillator nodeやgain node、filter nodeを使用すればもっと簡単に実装できるのだが。
フィルタのQが効くようになった。またしても凡ミス。LPFはいい感じだけど、HPFの動作がおかしいね。。
Youtube - 波形メモリシンセを作る-20191005
やっぱりレゾナンス効かせるとシンセっぽくていいなあ。。
LFO当たりの修正を加える。さらにシンセっぽい音が鳴るようになったな。。
Youtube - 自作ゲーム用の波形メモリ音源を作るー20191006
シーケンサに手をつけ始めた。シーケンサの構造を考えながら音源のポリ化を進めようかなと。パン二ングも実装せんとなあ。爆発音に必要なノイズジェネレータも実装せんといかんなあ。。
シーケンサの仕様が固まったので実装しつつ、仮想メモリ音源のマルチティンバー化も並行して進めている。8音か16音ポリのマルチティンバーとなる予定だが果たしてどうか。処理が追いつくのだろうか。。
多分音を鳴らすだけなら問題ないんだろうけど、ゲームのBGM用だからなあ。。フィルタの処理がやっぱり重いんで気になるところですわ。
シーケンサの動作確認用も兼ねてMMLみたいな簡易言語を作るつもりである。書いたらバイナリ・データにコンパイルするやつである。
SIMD使うと2音～4音くらい同時に処理できてパフォーマンスアップできそうだけどね。。
まあとりあえず全部組み上げてから考えよう。最適化は。。
悠斗@yu_to_0511
閃光福岡～！ #ラグビー日本代表 #ラグビー https://t.co/0weOYnwQSF
S.F.@SFPGMR
自作のwasmテキストフォーマット（S式）用のプリプロセッサのドキュメントを更新した。
#WebAssembly
S.F.@SFPGMR
いきなり停電。
#台風19号
この段階で停電するとは。。
とりあえずラジオをつける。手回し付きの充電器付き。
#停電
#台風19号
おお、復旧した。
#台風19号
冷蔵庫も停電時の保冷に備えて水を凍らしとかんといかんな。。
ちなみにスマフォの充電器は20000mのやつを2台確保ずみ。
さっき編集してたソースコードは吹っ飛びましたな。。
雨がすごいな。。
風が強くなってきたな。。
風は15号の時のほうがすごかった気がするな。。まだ油断は禁物だが。。
いやいやそんなことはないな。やっぱり怖いや。。
もう過ぎたか。。
風は強かったけど、15号の時のほうがヤバかったな。雨はあまり降らずに通過。まああくまでうちの地域はだけど。しかし他県は雨がすごくて氾濫・決壊か。。
S.F.@SFPGMR
@syntaxerrors72 この間の台風で玄関の門柱が破壊されたので、今回はどうなることやら。。地デジのアンテナが飛んでかないか心配ですが。。
S.F.@SFPGMR
@syntaxerrors72 マジでした。でも今は復旧してます。水道の水圧もなぜかおかしいです。。