今天看到一篇簡中文章. 描述了AI即興演奏的可能性. 大概看下來, 似乎作者承認即興還有困難, 不過隻是資源上的限製. 資源夠了, 完全可以和人一樣玩即興. 人玩機型的時候因為有主題和情緒, 所以實際上對人腦的算力要求小得多, 但是時間長了, 腦子會斷篇. 很難超過10分鍾而不亂. 機器卻沒有這個限製.
我雖不是專業, 但是大概理解的AI即興流程, 涉及到緩衝, 實際上人即興也是一樣的. 這麽看來, AI能力的邊界其實不是AI算法和玩法, 應該是肉人本身的極限.
換句話說, 肉人能做的, 隻要將肉人的行為模式分析清楚了, 告訴機器, 機器完全可以從方法論上模擬人的幾乎一切行為.
這麽看來, AI意識也不是不可能, 一旦人搞清楚了自己的意識真相, 秘密就回被AI攫取, 進而模擬出類人的意識. 這有點瘮人了. 人最好不要繼續研究意識了.
看完這篇, 感覺涼透了, 以為人在現場即興演出中還有優勢, 樂手們還有飯碗, 現在看, 不一定了. 搞個機器人殼子, 然後AI音樂給足了算力, 完全可以娛樂喝醉了的肉身們…
、音樂創作交互的即興反饋
不論做什麽，我們都繞不過去兩件事情。
第一件事情是音樂創作中的即興反饋。所有的計算都需要時間，尤其是AI模型。假設橫軸是時間軸，虛線時用戶進行了一次操作，想要更加勁爆一點的音樂。一般情況下是用戶操作完成之後，開始計算。計算時音樂會暫停，等計算好之後才會反饋。這樣帶給用戶的體驗很不好，中間需要等待很長時間。如果把計算時間縮短，在100、200ms左右或者更低時，可以算作即時反饋。但是這裏有一個難以解決的問題。音樂本身有節奏，會像一把尺子一樣衡量時間。即便是100ms的延遲，也會明顯感覺到這裏的卡頓。所以單純縮短計算時間不是最優解。還有一種想法是在計算時繼續播放，播放到一定時間點時，在合適的位置切斷。這樣帶來的問題是過於生硬。
那麽即興反饋到底是什麽呢？音樂播放時，用戶進行一定的操作，接下來計算的，不僅僅是接下來要播放什麽，而是接下來一段時間應該用什麽樣子的演奏方式使得它無縫銜接到你想要的狀態。音樂播放本身就是一個耗時的過程，如果計算時間小於聆聽所需要的時間，即興就可以做到。即興也意味著不再提前準備很多音頻播放，而是邊渲染邊播放。
這就牽涉到前端的渲染過程。首先看一下音頻引擎。以手機為例。手機有一個揚聲器，其背後有一個叫做音頻線程的東西。這個音頻線程一般是操作係統裏最高優先級的一個線程。它會把音頻分割成很小的切片，例如256個采樣點。在48000的采樣率下，大概一個切片的時間長度是5.3ms。之後將切片循環加入音頻，實現隊列播放。任何一個音頻文件，都會被切成很小的片段。音頻線程將切片移交給揚聲器，再通過回調函數獲取新的256采樣點的切片。如果不從內存裏直接給揚聲器切片，而是通過快速計算持續生成音頻切片，就可以實現實時播放。
在回調函數裏，放入圖中所示的連接圖，連接圖可以模擬類似混音台的功能。左邊類似虛擬樂隊的樂手們，每一個都會接受控製信號。之後就會在連接方塊裏進行DSP數字信號處理的算法。最後再進行一些加工輸出音頻。播放完成之後，再經過5.3ms，會有新的一輪回調，重複上麵的步驟即可。
雖然看上去很簡單，但是每一個方塊裏麵都是他自己數字音樂信號的結果，融合起來雖然很及時，但風險也是並存的。每5.3ms要消耗256個采樣點，這意味著每256個采樣點計算的時間都必須小於5.3ms。雖然增加緩衝可以降低要求，但是增加緩衝意味著延遲增加。想要盡量降低延遲，計算負載就不能太高。
下一個需要解決的問題是如何讓多個樂器可以同步播放。其實隻需要給每個樂器一個相同的播放頭就可以了。我們會設置兩個播放頭，紅色的叫做計算播放頭，黃色的叫做渲染播放頭。紅色的部分會先運行，稍早於實際時間。計算播放頭會動用一些AI算法，將中間生成的結果變成一個一個音頻控製信號放在緩衝區中。當黃色渲染播放頭刷過去時，會經過這些緩衝區的信號，全部發到相應的軌道上，就可以同步處理了。而且得益於提前一點的計算，不用過分擔心高負載。
選擇“Disable on www.wenxuecity.com”
選擇“don't run on pages on this domain”
