@puruya0122 ピアノジャックとかヒイズミマサユ機とかmouse on the keysとか（ちょっとマニアックかも）にインスパイアされていそうなところありますよねー。この人はいろんなスタイルの音楽を作れる人ではありますが。
Atsushi Eno(@atsushieno@mastodon.cloud)の投稿
@puruya0122 ピアノジャックとかヒイズミマサユ機とかmouse on the keysとか（ちょっとマニアックかも）にインスパイアされていそうなところありますよねー。この人はいろんなスタイルの音楽を作れる人ではありますが。
いわゆるアートコア（日本の）には→Pia-no-jaC←とかHZMとかmouse on the keysとかが影響を与えていそうだと思ってるけど、関連性があるような言及はあんまし見かけないな。
このアカウントは、notestockで公開設定になっていません。
JUCE AudioPluginHost（のAndroid版）だけ何か出音がおかしくて、InternalPluginは正常な音が出ているので自分のwrapperの問題だと思うんだけど、どこが悪いのかわからん…（日頃の開発風景）
自分が髪切ってるところおよそ女性向けなんだけど（男性客もたまに見かける）、最近いつも電話予約すると名乗る前に「…さまでよろしかったでしょうか?」って言われるので、間違えたら割とクリティカルだし何が理由でほぼ確実だと判断されているのか気になる
仕事では（コロナ以前）ずっとslack callsでオンラインミーティングしていたけどカメラなんて誰もonにしていなかった。
「アーティストのたなかさんと結婚」でえっぼくりりじゃん?って気づいた自分すげえ芸能界詳しくない? (詳しくはない) https://twitter.com/yukos_kawaii/status/1600384616820609024
DSPのABIはwasmにするのが一番ポータビリティが高そうだし技術的にも無理がないんだけど（しかもオーディオスレッドとのatomicな境界越えという点でも自然）、一番プロセスの境界線を超えてほしいのは結局DAW側で動いてほしいGUIなので、こっちはこっちでWebになっていてほしい。
それ以外の部分はアプリケーション単位で制限されたストレージアクセスとかを考えるとネイティブアプリケーション（ただしオーディオスレッドではないので言語は何でもいい）ってなるんだけど、これならプロセス単位でのアクセス制限さえ回避できれば（あるいはこっちを特別化できれば）全部Webテクノロジーで構築したほうがいいってなりそうな気もする。
一方で「最速」を目指すアプローチの中にはGPU、TPUその他カスタムチップの存否に合わせて最適なハイブリッドネイティブコードを生成するものがあって今後トレンドとなりそうな気がする。CmajorのJIT（実態はビルド時ではない実行時AOT）なんかはこのアプローチ。こういうのはwasmのポータビリティとは相反する。
CmajorのIRがどういうものかはわからないけど（ソース公開されてないし自分もIRは読み慣れていない）、wasm IRと近いなら基本はwasmとしておく路線はありだし、遠いなら相容れないアプローチとなるかな。
オーディオプラグインのために独自IRなんてちょっと構想でかすぎない?っていう気もするけど、Cmajorがやってるのはそれに近いし（オーディオプラグインというドメインには明示的には限定されていないけど、あの言語仕様で作れるのはせいぜいオーディオプラグイン程度でしかないはず）、Android NDKでもwasm IRが検討されているし、後方互換性の無いLLVM IRを基盤にするよりは現実的そう。