今日は特に日記に書くことがないですね。全部ついったーに書いたので。
問題を整理します
— phi16 (@phi16_) 2020年6月10日
完璧に動いた
— phi16 (@phi16_) June 10, 2020
…いろんな制約を満たしつつ目的を達成するプログラムを書くっていうのはこういう行為だと思うんですけど。こういうことを考えるということだと思うんですけど。
すごいしんどかった。みんなこんなことやってるんですか？プログラム書ける気しなくなってきた。
まぁ特にこれを出力無しでやろうとしてたのでこんがらがってぐちゃぐちゃになっていたので、こうやってどばーっと過程を記述して整理するというのはある意味では当然の行為なんでしょう。
いや考えてみれば頭の中で済ませる必要はないんだよな。特にこれは時間軸が結構関わってくる話なので絵に書きづらい部分があったんですけど…まぁだからこその文章か。
きっと絵じゃなくて文にしたほうが伝わることもあるんでしょうね。そんな気がしました。
さて。
なんだかんだでさらなる汎用性を手に入れたうちのこですが、結局音ズレに関しては何も治っていません。けど今日はそれの再調査をしました。しんどいことがわかりました。
まず根本的にUnityの音声処理系統は (観測上では) 8/375秒を基準にしているっぽいです。約0.0213秒、940.8sample。AudioSettings.dspTime も AudioSource.time も結局この枠組みに乗っています。きっと違う環境では違うのだろうけど。
で、AudioSettings.dspTime と AudioSource.time の変化タイミングは完全に一致していて、実質的に同じ時間軸を司っているとみなして問題なさそう。つまり AudioSettings.dspTime が必要だという要望は実はそこまで本質的じゃないということ。
どこかで書いた気がするけど、floatとdoubleの精度が違って云々～とかいうのは完全に的外れで、1/44100精度を担保するのには16bitあれば良いので100秒以内ならfloatでも十分。だからここで重要なのは絶対指定 (
Schedule) か相対指定 (Delay) かということで、丁度1時間0.01秒後に鳴らしたい、みたいなのはfloatだと足りないので絶対指定すべき、ということになる。でもこれって実質的に絶対指定したい人でしょ。遅延の範囲じゃないでしょ。
たぶんね。
で、じゃあ何が問題かということで、実際に同じような仕組みをC#で書いてみたところ、普通に綺麗に動いた。ズレなく。ついでにUdonとして再解釈してあげても、綺麗に動いた。
しかし、その状態で、動作を開始していなかった機構を動かしてみると、ズレが起き始めた。
つまり、端的に、重いとズレる説が出てきました。しんどいね。
まぁ引き続き検証することは色々あるんですけど、なんだか納得できる点もありますね。前にミニシーケンサ作ってたときは確かにコレで綺麗だったんです。
はー。なんとかなるといいんだけどな。
今日はその2つ以外に特に何もなかったです。ちなみに唯のPlaneだった床を前バージョンのテストモデルに差し替えただけでちょっとやる気が増えました。やっぱりそういうの大事だと思います。
機構だけのプロトとはいえ雰囲気は見ていたい。見てるだけでうれしいですしね。完成したワールドとかSceneViewでのんびり眺めてたりしますよね。
まぁとりあえず今まで止まり続けていた作業の手が動き出したのでよかった。コーラもおいしかった。
明日は引き続き調査と、あと結構前にもらったモノのちゃんとした実装をやろうと思います。予定通り。
…なんだか最近日付の変更が遅くなった気がするんですよね。日記を書いているからとか、VRChatにあまり行ってないとか、そんなアレかしら。
いやでも作業自体はうまく進んでいるわけではないのでやっていかなきゃいけない。やります。
土曜日にベースまで動いてたらいいな。
おわり。
