I’m working on a module that acts as a MIDI driver (sending MIDI). When my module is loaded first, it establishes the driver and a MIDI consuming module (e.g. MIDI-CV) shows up my driver correctly. Otherwise, when the consuming module is loaded before my module, it shows up no driver at all (because the driver has not been established before).
So when my module is placed into the rack by the user, is there a (save) way to smuggle my module to the first slot of the std::Vector modules in Engine::Internal?
Additional information: The problem only occurs after loading a patch that contains modules in the ‘wrong’ order. By rearranging the modules in the JSON-file, the problem can be solved, although this is not a user-friendly solution.
I assume you are talking about the “devices” of a MIDI driver? I had a similar problem some time ago, causing any MIDI modules resetting their device setting because midi::Driver::getOutputDeviceIds() returns an empty list while loading a patch, at least in my case.
Unfortunately I found no adequate solution, just an ugly workaround to make it work somehow (by returning a dummy list in midi::Driver::getOutputDeviceIds() if APP->history->canUndo() is false).
Yes, it’s about the presence MIDI driver itself and/or its devices. On the other hand, by using this technique I’m going to invent a new kind of invisible broadcasting-and-WIFI-style ‘cable’ inside the VCV Rack. Maybe this will confuse users, I don’t know.
A safe way (by using cables) would be to fork the modules MIDI-CV, MIDI-CC, MIDI-GATE and MIDI-MAP (and also similar modules). At the end this will not be a ‘good’ solution at all.
Yes, this is a kind of “trade-off” not having MIDI cables in Rack. Right now this is not a big issue as there are no plugins with custom MIDI drivers (as far as I know) but I expect this situation will change with Rack v2.
I think the preferred way is to register your MIDI driver when your plugin loads as there is no function to “unload” a driver after a module has been deleted from Rack.
Maybe you can work your way around by loading your driver in init() and having a fixed number of “virtual devices” in your driver which can be addressed from your VST. More or less how the “Bridge” driver and VST work…
These modules get their input (MIDI data) exclusively over MIDI-drivers. But I need either a cable input or a new MIDI-driver. And it’s fun to hack the rack.
