Hi Veg,
This must be the same problem as Laukku reported earlier:
viewtopic.php?f=24&t=47840&start=20#p596545And Kode54 has already written:
Yes, that is a BASS import bug, because it appears your VSTi MIDI Driver is somehow importing the wrong version of BASS.dll, even though it explicitly is supposed to be searching its own folder for it.
The problem is both VMS 1.x and vstmididrv are inprocess drivers that implicitly using bass.dll (and bassmidi.dll). So in spite of Kode54's trying to load bass/bassmidi.dll explicitly from its own folder it does not work if VMS 1.x has already imported the same dlls implicitly into the player's process. (You can see e.g. in Sysinternal's process explorer that because of inprocess behavior bass/bassmidi.dll is in the given player's (e.g. Van Basco's) address space. So if VMS 1.x has already loaded a different version of basss.dll into the process's address space vstmididrv cannot load its own version anymore.
The solution can be:
1. Uninstall VMS 1.x. Optionally try the 2.x branch since AFAIK it uses out of process driver behavior so the player's process does not use implicitly bass/bassmidi.dll anymore.
2. Try to replace bass.dll/bassmidi.dll in VMS working directory with the newer one that vstmididrv uses. It should work, there are no breaking changes in 2.4.x versions of Bass.
But in case of my own player FSMP I have experienced that in spite of no dll version conflict I still get sometimes 'error 5 cannot play bass channel' with my own bassmidi implementation after using either VMS 1.x or vstmididrv. So solution 1 is more secure.
3. Using LoppMidi + FSMP can also be a solution since FSMP is a VST and Soundfont host and midi router in one without conflicts.