[MIDI Mapper] Manage MIDI devices

[TimPietrusky]

Right now it's possible to use multiple MIDI devices in modV, but that brings problems for systems, that are changing the DeviceID in a non-predictable way (like on Windows 10).

• Add a MIDI device to modV (component)
  • Name, inputs, outputs, deviceId, uuid from modV
• In the MIDI assignments, just reference to the MIDI device
• Change the deviceID
• Add multiple deviceIDs per MIDI device (to fix the problem that the ID might change between computers and OS)
• Detect if a MIDI device with a name we already have is used, but with another deviceID (this can happen on Windows, that the device is the same, but Windows assigns a new deviceID)
• Create a visual mapping of MIDI button / knobs / slides

[2xAA]

This issue is referring to the MIDI assignment plugin. Not only the general functionality of the plugin, but the control panel also.

Can we spec out these checklist points please? They're currently very ambiguous.

[TimPietrusky]

We will start working on this again for modV 3 and make sure to plan everything right.

[2xAA]

@TimPietrusky "VIRTUAL DEVICES"

[2xAA]

Something like this I think.

// Virtual control surface
// --
// inputlink <-> virtual device
// MIDI learning can be interfaced with the virtual device,
// a new i/o link can be created automatically

// Virtual Device should be created for any device automatically
// e.g. When a MIDI device is connected, a virtual device is created
// e.g. When an OSC "device" is connected, a virtual device is created
const virtualDeviceWhichWillbeSavedInPreset = {
  id: "someid-0000-ef4d",
  name: "Virtual Surface - KORG nanokontrol",
  io: {
    "someid-or-incremental-number": { /* inputlink details */ }
  }
}

const midiDeviceDataWhichWillBeSavedInPreset = {
  deviceId: "KORG nanokontrol", // can be updated via UI
  assignments: {
    66: {
      virtualDeviceId: "someid-0000-ef4d",
      io: "someid-or-incremental-number"
    }
  }
}

// We'll keep the existing MIDI device structure, outside of presets

[2xAA]

https://webaudio.github.io/web-midi-api/#dom-midiport-id

This explains how to hash a MIDI device (maybe) based on available properties.
We could probably extract this out to a utility module and put it on npm - could be helpful for others.

[TimPietrusky]

@2xAA I think I already looked at this and it was not working on Windows, but I'm happy to take another look 🙏

[2xAA]

@TimPietrusky Perfect - thanks!

[HorstBaerbel]

Please add the task: Make MIDI assigments editable manually
This might be needed if other sources send MIDI and not just simple button presses / knob values. I tried to use the MIDI for light script in Mixxx and it's impossible to make it work using "Learn"

[2xAA]

@HorstBaerbel do you know what Mixxx sends? Learn should work on any channel and any non-sysex message.

[HorstBaerbel]

@HorstBaerbel do you know what Mixxx sends? Learn should work on any channel and any non-sysex message.

Agreed, That script is probably a bad example, because it sends multiple messages at the same time, so the first messages gets learned (which might not be the right one). I was successful by editing the preset JSON manually, but that's a bit fiddly ;)
I known this is a niche requirement, but a MIDI overview page for a preset might be a good idea anyways, because all those connections hide in the depth of the modules / parameters. That page could maybe be used to edit the connections.

EDIT: There's an overview over the Mixxx MIDI output here.

[2xAA]

Thanks for the info! No case is too niche tbh. modV is itself quite niche, haha.

The node graph editor I mentioned a while ago (here), well I went and fixed it up.
https://github.com/vcync/vGraph

I'm planning, in the long-run, to allow MIDI routing via a node graph interface, which will make any sort of assignment possible. We'll still have a learn button on an input node, but also the ability to set exactly which channel and message(s) to react upon!