The internal DSP cards are great on a PC but you are back to contolling them much like any other VST, that is either via Rewire or a convoluted audio loopback setup if you want to use the plug-ins alongside Reason.īasically if you are planning to spend that kind of money on a PC based solution I'd suggest talking your requirements through with a specialist builder like ADK or booking a consultation with someone like Jim Roseberry at Purrrfect Audio.
REASON AUDIO LOOPBACK DRIVERS
UAD Apollo Duo and Solo drivers don't exist for Windows even if you have a Thunderbolt equipped PC.įor the Apollo and Apollo 16 cards check out the support page before thinking about a UAD interface on a PC especially with regard to a qualified firewire add-on card.
REASON AUDIO LOOPBACK CODE
ProTools supports AAX plugins which contain the code for both the DSP system and the CPU and thus can switch them between the DSP box and the CPU. The plugins are programmed and compiled for an Intel CPU and simply won't run on the DSP hardware. Normen wrote:You can't just plug in a DSP processor to a computer and make it run the native plugins, that doesn't work with any system. But of course you can measure and compensate that with the VMG-01 RE
REASON AUDIO LOOPBACK FULL
You can also directly record the processed signal, just as if you'd have a real compressor on the analog side before your audio interface input.įor using Apollo in Reason it would work pretty much exactly as it would if you'd connect real hardware to your multichannel audio interfaces inputs and outputs, so you always get the full roundtrip latency for this solution. ProTools supports AAX plugins which contain the code for both the DSP system and the CPU and thus can switch them between the DSP box and the CPU.Īnd yes, with a DSP based system like the Apollo you can listen to the input latency-free, similar to your audio cards input mixer but you can put the (DSP-based) plugins of the DSP system on the monitor mix without adding any latency.
Wrap it into a shell script as above.You can't just plug in a DSP processor to a computer and make it run the native plugins, that doesn't work with any system. Then instead of loading module-loopback, start a program that reads from the mic source, does the clean-up, and outputs to the speaker sink. There is a background microphone hiss, which would be nice to clean up using a program rather a very simple redirection. Yes, non-technical users may still need to run the shell script again if something goes south on the system, but that shouldn't happen more frequently than other troubles non-technical users can't solve. Then make sure that script gets executed when the user logs in (because in their wisdom, the Pulseaudio devs don't support systemwide Pulseaudio by default). You can wrap the whole thing into a shell script (that also can unload existing module-loopbacks before adding a new one). This is a fairly technical process and the non-technical users I plan to provide this setup to may experience trouble if the system goes down for any reason.
See the module documentation for details. You probably need to specify which sources and sinks to use with module-loopback. I could not replicate this on another machine.
0 kommentar(er)
