很久没发过纠结贴了，来一个，确实也是挺纠结的。

因为现在的电脑其实性能不差， 理论上在同一个工程里完成所有乐器的编曲，然后再让歌手录音，再挂修音，再最后联合人声一起混音，是没什么硬件障碍的。
但是，注意到我上一句提到的“最后联合人声一起混音”，意味着，在录人声之前已经有对乐器进行了混音。
那么，在众多混音或音效处理插件中，有些是带有固有延迟的，比如多段压缩器之类的。
引入个2048个采样点（相当于44100Hz下的46毫秒）的算法延迟是很正常不过的事情。
那么，宿主都是有延迟补偿的，在编曲工程里录人声，实时监听的延迟就会至少有46ms的延迟。对歌手的发挥肯定是会造成问题的。

而有些宿主，是支持一键关闭所有带有延迟的插件（包括最古老的Cubase 5）。
但是关闭后，伴奏听起来和原来还是有很大差别的，同样影响歌手发挥。

而且，很多人也发现，当乐器使用了Key switch后，反复回去再播放，只要不触及KSW的音符，就会使用最后一次激活的KSW奏法。
这样会在反复录某一段的时候，部分乐器的奏法短时间内不正确。
这样同样会导致给歌手录音影响发挥。

注意这里我都不会提到什么内存、CPU不足，硬盘转不过来等用钱就能解决的音素……

而且，在众多录音棚里，其实也不太可能装上所有的音色库，和所有的音效插件。
这样如果要去录音棚里录音，其实最现实的方法，
依然还是只把伴奏导出一份，然后用独立的工程，给歌手录好干声后
再拿回工作室做混音的吧？

这个混音就基本都是和原编曲工程混在一起即可，因为已经没有实时录音监听的必要性了。

这里想了解一下，各位是否是一站式、单工程来做一个编曲+录人声+混音的呢？


==术语解释===
算法延迟，不因为CPU和内存多高级就能变小的东西。
比如一个算法就是需要囤够2048个采样才能做一次运算（比如FFT），那么你的整个工程的最小延迟就是2048个点（46ms）。

延迟补偿——当一个音轨的固有延迟为A，那么为了让所有音轨与之同步，都推迟A延迟。比如用来录音的人声轨，就会因此而产生最低A延迟的实时响应。