Heh, just occurred to me that ASIO drivers likely were meant for cards with multiple output options anyway (not certain on that, though...) so technically this might not be a 'feature request' so much as it is an 'oversight correction' ;)

I'm just sayin'
:D

I'd rather say it's a limitation and not an oversight.

Any hope of this getting added to the queue of things looked at in the near future? Though I've kind of gotten used to working the way I've been, it'd still be quite a nice thing to have.. Especially if, as I believe you've mentioned previously, it seems to be something of a rather simple nature to change.. o:)

I have started rewriting the necessary parts half a year ago, but I want to do it properly from the beginning instead of adding hacks here and there, so it probably won't it into OpenMPT 1.20.

i am hopeful at seeing a release go out.. ;)

i've recently been having some more latency and/or performance issues with all the large samples i use (been running them as VSTs as my former setup choice of using MIDI with a stand-alone player has been horribly laggy for the past few songs i've been trying to work on..) -- and .. yeah. i'm hoping to see light coming from the ol' "ASIO output selection" project.. if only we could route a VST to an ASIO output (or bus), the tracker (ie: sampled/tracked material) to another ASIO output, and then the other big VST i use to it's own ASIO output... My 'bottleneck' seems to be the amount of stuff i'm trying to push thru one audio bus. The hardware will run 6 busses lag-free.. but currently there are no hoops i might jump through so as to earn tolerable playback (as it's all crammed into one bus).. At any rate -- just wanted to drop in and encourage you. :) VERY appreciative of all the work you're doing -- and a good job of it, you're doing. :) Thanks. :)

If you split up the audio on several ASIO outputs, you will just get even more problems - it will not remove any bottlenecks, on the contrary, it will create them. OpenMPT would have the double amount of data to process, and it would have to sync the two ASIO outputs so you don't get any nasty delays between the two channels.

As a sane implementation of an ASIO channel selection dialog is still likely to take a while, I have added a temporary workaround: In mptrack.ini, you can now add the line ASIOBaseChannel=x in the [Sound Settings] section, where x is the first ASIO channel to be used by OpenMPT. By default, x is 0, so if you want to access the second stereo channel pair, you'd use ASIOBaseChannel=2, the third pair would be ASIOBaseChannel=4 etc...
http://sagagames.de/stuff/mptrack.exe to try it out.

This works! Having it be an option(al option) within the INI file is 100% acceptable to me and solves the issue. i really don't see any need for having it be part of the in-program sound card settings (at least, not for my purposes). Seems it's likely an advanced feature anyway, so the fact that it could be modified only in the INI file does seem appropriate. ;)

THANK you very much! :D

I'll keep it open for now, because having an ASIO channel selection screen is something that most programs supporting ASIO have, so I guess it makes sense to have one. But good to know that it's working for you.

This hidden setting is now part of the GUI.