Seems nobody sees a merit in it.

The advantages should be clear, you would not need to sacrifice "precious" HW ouputs for loopback recording
that you might need better for connecting devices.

Nobody ?

Perhaps a few more thoughts on this.

1. an implementation would have to be fully compatible to the current situation, so that everything can continue as before.
Especially because of the peculiarities/limitations of some applications (zoom) to use only the first two audio channels as input.

2. that's why these virtual loopback channels would have to come at the very end in the order of the ports in my opinion.
Unless the order of the channels would (can) be made configurable in the driver, which is already on the wish list of Protools users, because Protools has a 30ch limit on the part of Avvid (for non Protools HD solutions).

Question is, whether this would be possible, whether the FPGA would offer enough space for (ideally) all products to make something like this possible.

@RME: would this proposal qualify to come onto a wishlost or is this fully out of sight ?

As you see there is some interest and other customers might also be happy as there are valid use cases for it, esp. for Apple customers when using Digicheck as has been mentioned e.g. in post #9.

Would solve this too:
https://forum.rme-audio.de/viewtopic.ph … 69#p176469

Was just thinking how this could be implemented.

Requirements
1. current loopback functionality needs to stay for backward compatibility
2. additional channels for loopback (lo1 - lo8) need to go to the end
3. virtual loopback channels have the same features as real HW channels (FX, mono/stereo button, ..) they only have not I/O port (input/output) to the outside
4. amount of loopback channels: ideally something in the range up to e.g. 16 ?!
   Might be recording interface dependend, how many resources are available for this.

Two Levels of implementation:

A) Step 1: "easy basic implementation", same operation, no change in the TM FX GUI
- you route audio to the virtual HW output lo_x
- there you can click loopback and can record audio on corresponding virtual HW input lo_x

B) Step 2:  you want to use loopback on a real HW output, but not "overlay" audio of the corresponding HW input
- implement loopback as pulldown menue
- if you click the loopback button short, you get loopback on the corresponding HW input (old style)
- if you click the loopback button a little longer you get a pulldown menue where you can select
   - corresponding HW input
   - list of available loopback channels
- if loopback is active the "loopback button" shows the loopback channel name instead of only "loopback"

While doing this it would be very useful to have an option to choose, whether loopback works pre- or post-fader.
Also two options here
- as global setting with default to pre-fader so that it is possible to mute a HW output without impacting loopback operation
- on a per channel basis (maybe implemented to be selectable in the above proposed pull-down menue
  This should be signalled somehow, maybe as little glowing bar over/below loopback button