IResourceProvider seems not to dispose Resource

Hey, I currently encounter a bug with VL.IO.Midi, MidiIn.
When having a MidiIn in the patch, the vvvv process stays alive when closing vvvv.

Debugged it with VS and the process hangs inside Sanford.Multimedia.Midi DelegateQueue.DelegateProcedure() at Monitor.Wait(lockObject) because the InputDevice is not disposed.

 private void DelegateProcedure()
                // Signal the constructor that the thread is now running.

            // Set this DelegateQueue as the SynchronizationContext for this thread.

            // Placeholder for DelegateQueueAsyncResult objects.
            DelegateQueueAsyncResult result = null;

            // While the DelegateQueue has not been disposed.
                // Critical section.
                    // If the DelegateQueue has been disposed, break out of loop; we're done.

                    // If there are delegates waiting to be invoked.
                    if(delegateDeque.Count > 0)
                        result = delegateDeque.PopFront();
                    // Else there are no delegates waiting to be invoked.
                        // Wait for next delegate.

                        // If the DelegateQueue has been disposed, break out of loop; we're done.

The InputDevice is created by a IResourceProvider inside VL.IO.Midi

 public class MidiInObservable : MidiObservable
        private readonly int FDeviceID;

        public MidiInObservable(int deviceID)
           : base(CreateMidiInResourceProvider(deviceID))
            FDeviceID = deviceID;

        public bool IsOpen => ResourceProvider.ExistsInSystemWideProviderPool<int, InputDeviceMidiEvents>(FDeviceID);

        static IResourceProvider<InputDeviceMidiEvents> CreateMidiInResourceProvider(int deviceID)
            return ResourceProvider.NewPooledSystemWide(deviceID, id =>
                var midiInDevice = new InputDevice(id, false);
                return new InputDeviceMidiEvents(midiInDevice);
            .ShareInParallel(delayDisposalInMilliseconds: 250);

The ResourceProvider returns InputDeviceMidiEvents which it (afaik) should dispose when “no one” is using it anymore, which in turn would dispose the InputDevice. But that doesn’t happen.

To reproduce just open the patch and then close vvvv again look for the vvvv process in the taskmanager.
Tried it with vvvv versions down to 2021.4.0.

ResourceProvider.vl (3.8 KB)


Ok tested once more and the behaviour is caused by ShareInParallel(delayDisposalInMilliseconds: 250);
It works when the delay is set to 0.
Should I make an issue on github or even a pull request?

1 Like

Thanks for the very detailed report. The culprit was indeed the delay of the dispose call. To address this issue at very root, we’ve added a OnExit event which gets triggered when the patch stops (or the exported application exits). The code path delaying the dispose call will subscribe to that event.
Bugfix will be in next preview.


Hey guys,

Sorry to be the party pooper but it seems this bug is still here for me using the 2021.4.11 Stable ;(

  • whenever I launch a patch with a MidiIn node, quitting vvvv results in a ghost vvvv.exe process I can spot in the Task Manager.

  • if I relaunch my patch without killing the ghost process first, no MIDI will be received at all.

  • if I kill the ghost process before I relaunch my patch, MIDI will work as expected

  • interestingly, if I launch my patch and quit vvvv multiple times in a row without killing the ghost processes in between (and thus still having no MIDI working), it adds up another instance of a ghost process in the Task Manager.

Hopefully this will help diving it and getting this annoying bastard once and for all!
Let me know if there’s anything I can help with and test on my side

Oh no!
Sorry to hear!
Thank you for your patience and report though! We’ll give it another close look.

@TremensS we cannot reproduce this on our end since 2021.4.10

please add more infos:

  • does this happen with any midi device (which?=
  • does it also happen if you don’t have any midi device attached to the pc at all?
  • does it also happen on other pcs?
  • please share a patch (as simple as it may be) with exact steps to reproduce