|
|
Member
Posts: 19
| Hi all,
I'm having some strange problems using Revisit as a plugin in REAPER with the MIDI-out functionality. Sometimes - around 50% of the time - when I close and reopen a project with a Revisit instance, REAPER pops up a message saying it cannot open the midi output to my synth, and then the track no longer outputs midi since the device no longer shows as a selectable option. Once I remove the revisit instance, the device is available again. Revisit is somehow locking the MIDI device but I can't find any settings to make revisit ONLY use the 00: VST Host option and not ping for other devices. Does such a setting exist?
Additionally, if I have revisit in a project open, and I go to the REAPER settings and try to enable a midi device, I get the same warning message.
Are there any solutions to this?
Thanks! |
|
| |
|
Developer
Posts: 746
  
Location: England | Hi James,
Welcome to the forum! It sounds like you have encountered a rare, but perfect storm of MIDI - a collision of specific drivers, host and plugin.
Some MIDI drivers are single-client, meaning that any software that uses them will "lock" the MIDI device for exclusive use, preventing other applications from successfully opening the port. Because not every host supports the built-in VST mechanism for passing "MIDI" messages to the host, reViSiT additionally offers direct access to MIDI drivers. Obviously, this creates a potential conflict between the host's and plugin's attempt to use the driver. It seems reasonable that reViSiT's claim should be subordinate to the host, which is how it usually works - the host claims the MIDI driver, then when reViSiT loads, it is no longer available.
Unfortunately, it sounds like REAPER is a little random about the way it starts up. A host often part-loads it's plugins during loading, and normally this is done after it has the basic systems like MIDI and audio already initialised. However, I think REAPER tries to do both these things at once (in separate threads), such that it becomes a race as to who gets to grab MIDI devices first. REAPER does load a lot quicker than other hosts, and this could be the price.
I've not had reports of similar errors in the past, which presumably means most drivers are multi-client, or other hosts are more careful with their startup. For example, in Cubase, I seem able to use MIDI devices in both the plugin and the host, without conflict - though it's possible Cubase has more advanced / flexible MIDI support. Things might have also improved in more recent versions of Windows (it would be sensible for the OS to lock the device, then itself accept, mediate, and merge MIDI requests from multiple applications).
Let me know about your host (version and whether 32-bit or 64-bit), your MIDI interface (make and model) and OS (version and whether 32-bit or 64-bit), and I'll see if I can code some kind of workaround. This might be a setting disabling reViSiT external MIDI support (possibly, initially, requiring an edit to the config file), or maybe a method to detect when reViSiT is "part-loaded", so that it doesn't try to initialise MIDI support before REAPER does. It may also be possible to defer initialising MIDI devices until they are actually used in a song, though I'm not sure how feasible this is in the current codebase.
All the best,
Chris
|
|
| |
|
Member
Posts: 19
|
Some MIDI drivers are single-client, meaning that any software that uses them will "lock" the MIDI device for exclusive use, preventing other applications from successfully opening the port. Because not every host supports the built-in VST mechanism for passing "MIDI" messages to the host, reViSiT additionally offers direct access to MIDI drivers. Obviously, this creates a potential conflict between the host's and plugin's attempt to use the driver. It seems reasonable that reViSiT's claim should be subordinate to the host, which is how it usually works - the host claims the MIDI driver, then when reViSiT loads, it is no longer available.
Unfortunately, it sounds like REAPER is a little random about the way it starts up. A host often part-loads it's plugins during loading, and normally this is done after it has the basic systems like MIDI and audio already initialised. However, I think REAPER tries to do both these things at once (in separate threads), such that it becomes a race as to who gets to grab MIDI devices first. REAPER does load a lot quicker than other hosts, and this could be the price.
Aha, makes sense.
Anyway, I have PM'd you the requested info. Let me know if you need anything more. Hope you can figure something out! 
Perhaps just an INI flag or something to completely disable Midi Driver loading would work?
Edited by jamesh 2012-10-26 11:18 AM
|
|
| |
|
Developer
Posts: 746
Location: England | Hi James,
I was unable to replicate the issue on my system - using REAPER 4.261 32-bit / LoopBe1 / Win7 64-bit. However, I have made a couple of changes that should allow you (and other REAPER users) to work around the issue: - Adding disablemidi="1" to the reViSiT.ini file (explore "c:\%LOCALAPPDATA%\reViSiT\") will prevent reViSiT trying to open MIDI devices at all.
<preferences ... disablemidi="1" ... />
("VST Host" will still be available for passing MIDI messages from reViSiT to the host, though you will obviously be limited to 16 channels.)
- Any MIDI device that is disabled (or already in use) will be grayed out in the MIDI Device lists in the Instrument List (F4).
I'll email you the new build (1.7.1.2) to try out - let me know how you get on. If all looks good, I'll schedule a wider release as 1.7.2. Best,
Chris |
|
| |
|
Member
Posts: 19
| Works perfectly! The MIDI interface that was locked before is now greyed out in ReVisit, so for my interface I didn't have to use the new INI setting.
However, after loading if I tried to enable another interface (LoopBe), I still got the error. After applying the INI fix, this problem went away, so both issues are fixed.
Everything looks good to me, thanks for putting the time in to fix this |
|
| |
REAPER and ReViSiT MIDI Output Conflicts?
