Vienna Symphonic Library Forum
Forum Statistics

181,973 users have contributed to 42,196 threads and 254,641 posts.

In the past 24 hours, we have 2 new thread(s), 7 new post(s) and 46 new user(s).

  • VEPro, MIDI port name/index ISSUE v6.16178

    last edited
    last edited

    Error: Incoming MIDI messages arrive in VEPro mapped to the wrong port.

    PC (i7) Win10x64 (creators update)
    Class compliant USB MIDI interface > MIDI-OX v7.0.2 > LoopBe30 v1.6 > VEPro v6.16178

    Steps to Repeat:
    1. Open MIDI-OX, select all incoming physical/virtual ports and all outgoing physical/virtual ports
    2. Play notes, monitor keyboard events as test of physical port identity
    3. Join one wire only in MIDI-OX, between that specific hardware port and LoopBe30 virtual cable 1
    4. Open VEPro6, assign a new plugin, configure MIDI input to Loopbe30 virtual cable 1, ALL channels
    6. Play notes - no response from VEPro6 (no sound, no MIDI activity) - ERROR
    - Named port and channel should work

    Steps to relax filter:
    7. Change VEPro to use ALL MIDI inputs, ALL channels on the plugin
    8. Play notes - plugin will sound
    - This bizarrely implies that MIDI is *successfully* arriving, but being routed some other way

    Steps to investigate port sharing:
    9. Adjust VEPro channel to select the PHYSICAL input port, previously set up in MIDI-OX
    10. Play notes - no response from VEPro (no sound, no MIDI activity) - ERROR
    - selecting the operational physical MIDI port should work (multi client)
    - this *COULD* imply MIDI is not being provided in a multi-client device driver (although port sharing has not been a problem to now, that I remember)

    Steps to investigate mis-mapping:
    11. Now Select each MIDI input in turn in VEPro in the plugin
    12. Play notes - until you find the one list item works - ERROR
    - The successful named port is not the one being used in the configuration

    a) I suspect portname/index mismapping issue
    b) It does not appear to be an "error of 1" because although the port numbering is arbitrary per software, the error is not corrected by selecting an entry either side of the desired connection
    c) I suspect this is caused by the port-sharing problem - my guess is that the "open device list" does not match the operating systems reported available input ports - perhaps attempting to open ports which are in use by another application fails means they are NOT enumerated in same list as the operating system's original device list. Hence the name in the dropdown will point to the wrong index in the open port array.
    d) Microsoft have provided a Win32 rtMidi wrapper for the Win10 UWP MIDI API, but developers are reporting issues with virtual MIDI ports - see blog notes in (2017/08/15)

    On my system there are 17 active MIDI inputs - RME UFX 1 2, Launchpad, ESI4x4 1 2 3 4, LoopeBe 1 2 3 4 5 6 7 8 9 10. In MIDI-OX, ESI 4x4 2 was routed to LoopBe out 1of10 in MIDI-OX - please see MIDI-OX Setup
    Please note the successful input port was a complete surprise to me - 3 Launchpad
    Port options as listed in VEPro

    - the ability of MIDI-OX to monitor ports depends on what order you open the software apps. implying one or other software apps is not playing nice when the user is MIDI port sharing.
    - AFAIK all my USB devices are WDM Kernel mode, and therefore multi-client friendly, but I am still investigating this aspect of the problem. Attached devices are RME UFX, Novation LaunchpadS, and ESI 4x4.
    - as a control, I also tested this in Ableton Live 9.7, and the MIDI ports are listed correctly and map correctly, so I think this is a VEPro list map issue, not a general setup problem

    1) Use MIDI-OX as a buffer the physical ports, and route each physical to an equivalent virtual cable.
    2) Open only virtual cable ports in Ensemble.

    Further reading, new Win10 UWP MIDI:
    MS have made all MIDI ports multi-client by default, hopefully such port problems will be eliminated in the future.