Built-in loopback support

[brownounces]

It would be extremely beneficial to incorporate a built-in WASAPI/DirectSound/MME loopback option for sampling straight from a PCs sound output, since this is ultimately a software sampler. Audacity, as far as I know, is the only program with such a refined implementation of this, which allows for the simultaneous monitoring and recording of sound from within the computer. It is apparently done through PortAudio and a loopback patch which could possibly be applied to this program?

[izzyreal]

Some notes:

1. Based on https://learn.microsoft.com/en-us/windows/win32/coreaudio/loopback-recording, only WASAPI shared-mode is supported. Though I haven't noticed much performance difference between WASAPI exclusive vs shared, having a feature that is only for Windows, and only for WASAPI, and only for a specific WASAPI mode, is not ideal, because it results in feature discrepancy (and what we want is feature parity -- the same functionality regardless of OS or audio API). By the way, if you discover similar loopback APIs for DirectSound/MME, please let me know by dropping a comment.

2. WASAPI Loopback is not like having a dedicated loopback device like Virtual Audio Cable. Instead, it's a mechanism to tap into all system-wide WASAPI output combined. This introduces the risk of feedback if the user enables monitoring in VMPC2000XL's SAMPLE screen. If VMPC2000XL were to support WASAPI Loopback, monitoring in the SAMPLE screen would have to be disabled, but only for this specific case. It would require making https://github.com/izzyreal/mpc aware of the fact that shared-mode WASAPI Loopback is enabled.

3. VMPC2000XL delegates to JUCE for talking to (virtual) audio interfaces, and JUCE does not support WASAPI shared-mode Loopback. I'm ok with doing small patches to JUCE, since I already rely on a fork anyway, but the WASAPI Loopback API requires a lot more than that. It would require quite an invasive hack in JUCE, as the PortAudio patch illustrates. Assuming for a moment the hack would work well, keeping the fork synchronized with such a hack becomes a maintenance burden.

Considerations 1. and 2. may well be the reason why almost nobody (including JUCE) is implementing it.

But I will give it some more thought. Just because it's far from ideal does not mean it should not be added to VMPC2000XL. I can see how nice it would be to have this feature.

[brownounces]

I figured there was a reason it was a scarce function, and I totally agree with the premise of feature parity. Truthfully, it does not matter if it employs WASAPI/MME/DirectSound if the desired function is achieved. Maybe a more universal solution, compatible with all operating systems, is a better idea.

Another possible consideration: perhaps a preset 'virtual cable' could be added specifically for the VMPC2000XL software that would enable similar functionality. Using VB-Cable, I've got a hacky solution that enables sampling directly while not infringing on normal playback or monitoring. If you or anyone reading this is interested, this is the method:

1. Install VB-Cable and set both the CABLE Input and CABLE Output devices to be the default.
2. On the recording tab, select the CABLE Output device and open Properties.
3. Select 'Listen to this device' and select your desired playback device.
4. Ensure that the sample rate of the CABLE Output matches the sample rate of the playback device, or it will sound like a gurgled mess.

If a similar solution could be made, but automatically configure itself if selected as an option, I think it would greatly encourage people to use this as a sampler. I imagine that many people experimenting with this software emulator likely have little or no hardware to physically sample from or to loopback their PC audio.

Of course, I don't intend to make impertinent demands, especially when I myself am not capable of implementing these features. I only hope to offer some ideas.