Fair question, we are mostly avoiding midi.
The reasons not to use midi directly:
Snapshotting ALL params on the device
When moving from base parameter set (no scene) to scene 1, we need to know the start values of the parameters otherwise we risk jumps.
There is no way to poll the device to have it dump all the midi values it contains.
Midi jumps (pickup mode)
I haven’t been successful getting pickup to work on Elektron devices with external controllers, and even if supported it’s not a viable solution to avoid jumps.
Imagine this case:
- Move the scene fader half way
- adjust an individual param
- Continue moving the master scene fader
With just mifi we will get jumps, or abandon that param on step 3.
With vst, we know the last val I manually adjusted to, and can interpolate from the new value smoothly when the scene fader moves again.
VST spec creates easy (and auto generated) mappings
This is just dev qol, I don’t need to worry about what channels or cc to send, whether to use nprm or other.
The controls are registered in the VST itself, it is trivially easy to know what I can control and how.
We actually DO use midi a couple places:
-
To consume pattern / bank changes, that data is oddly enough not surfaced in the vst (from what I can tell)
-
To consume clock and transport for automated fader sweeps
That being said, there is nothing wrong with the midi approach, which is how the drop is built, and it’s obviously a super cool machine.
There is room to expand this to support generic midi as well, and support other devices (as you suggest)
But for elektron specifically we can squeeze out a couple finishing touches via VST.