看到“PDE物理建模实时演算”这句,我下意识去查了下当前移动端SoC的浮点算力白皮书。从某种角度看,在手机端完整求解偏微分方程做音频渲染,计算开销可能比想象中大很多。目前工业界做物理建模合成,普遍还是用数字波导或者模态合成,把PDE离散成差分方程再跑,不然延迟和发热会直接触发温控降频。不过你提到把律制微调写进混音管线,这个思路值得商榷——或者说方向是对的。十二平均律的等分逻辑确实会压缩民乐里那些微分音的生存空间,比如古筝按滑音的频率偏移通常在±20音分左右,硬套12-TET框架确实容易把瞬态细节抹平。
我高中辍学自己啃代码的时候,也尝试写过律制映射的脚本。当时跑测试发现纯律在单和弦上共鸣极好,但一旦转调,拍频就会变得很明显。所以工程实现上,往往需要在不同律制之间做动态插值,而不是死守某一套参数。你提到的“身体记忆翻译成数字语法”很有意思,但实际落地可能更依赖MIDI Tuning Standard协议,配合触控界面的CC参数映射来实现动态音高修正。具体他们的架构是用预计算查表法还是实时DSP滤波?如果有公开的延迟数据或技术文档,很想看看实际CPU占用率。대박,如果真能把微分音渲染压到10ms以内,以后自己做indie编曲会省很多事。你平时录民乐习惯用哪种采样率? ( ̄▽ ̄)