I’m using a Roland SPD-X as a midi controller, and I’d like to use it with MIDI-GATE, but I’m finding that there’s a limit to how fast I can play before the gates produced by MIDI-GATE just form one long open gate.
This is due to the fact that if you’re playing really fast, the note-offs of preceding notes are so close to the note-ons of followup notes, and it gets converted to one long gate.
What would be really nice is if I could tell MIDI-GATE to only use note-on events to generate 1-shot triggers (and otherwise disregard note-off events). Note that I can kinda get something working using RTRG when using MIDI-CV, but MIDI-CV makes it much harder to independently route different drum pads to different outputs/cables/routes.
Is there some other drum-friendly plugin in the wild that converts midi note-ons as triggers?
Here’s a visual aid for the behavior I’m seeing now vs the desired “note-on-only” behavior:
A gate-to-trigger won’t work here; it needs to be at the midi-to-gate/trigger conversion layer, otherwise it’s already too late: if my drum midi brain is producing 10ms midi “gates”, then I won’t be able to play drum hits faster than 10ms, or else it’ll just form one long gate. I really need something that takes only the "note-on"s into account when converting to CV.
Thanks for the GH issue link, you’re right it’s related to that issue and ultimately this one and specifically this comment.
I was actually mistaken in my understanding of how my midi controller was sending midi events. Here’s a slight refinement:
By default, a drum hit produces a 10ms “midi gate”; a note-on event followed 10ms later by note-off
That said, if you start playing notes rapidly, it’ll send note-off’s much faster to terminate each note-on before sending another note-on.
In other words, it’ll always send the correct alternating sequence of note-on/note-off (previously I was thinking it’d send consecutive stacked up note-ons before sending a bunch of note-offs in a row, but I suspect that actually might violate the MIDI standard.
But what happens is that when playing fast, the edges of notes [note-off,note-on] are less than 1ms apart, and (if I understand correctly) they’re getting processed in the same VCV engine step, and the VCV API doesn’t currently expose this kind of intra-step timing.
I can’t get around the “notes less apart then 10ms” - that is 100Hz. I assume you want to program flams and rolls, wouldn’t it be better to use a module for that and just trigger that with one note? Or am I not getting something?
I’m not really sure what you are trying to achieve, Midi has some basic technical limitations:
With its data rate of 31250 Bit/s and note messages been 3 bytes long plus start/stop bits you get a maximum “trigger” rate of about 520 Hz for one single note on a single Midi channel, at least theoretically under ideal conditions (like, no clock messages, no other notes, no other channels).
That been said, Rack does process audio in blocks (which size is set as “blocksize” on the Audio module) and causes the calls of MIDI-CV’s process are not evenly spread across a second as a sample rate of 44.1kHz (or any other samplerate) might suggest. In contrast, Midi messages are been processed by modules as soon as they arrive. This causes Midi clock jitter in Rack v1 and in your case, some weird behavior on fast note messages. To summarize, there is no hope getting this work reliablely in Rack v1.
What might work is converting your Midi messages to gates on the hardware side and process these gates in Rack using an audio input.
Honestly, if there were just a “note-on only” mode (I think it’s called one-shot mode in other contexts/DAWs) in MIDI-GATE (wherein it just listens for note-ons and converts those to, say, 1ms triggers/gates) I think that would solve my problem. It’s not the density of note-ons that’s the problem, it’s the fact that the note-offs that terminate the preceding note are happening within 1ms of the note-on of the next note, and the result of this is just one long uninterrupted gate.
Okay, I think I get it now. How about a clock that runs at double the speed of your fastest consecutive triggers and that terminates a possible gate on every second beat? You could use a switch or a flip-flop with reset.
Maybe you could use a polyphonic MIDI-CV module with 2 channels, split the signal, apply a mechanism for gate-to-trigger and add them back to a single channel with an adder or or-logic?
Yeah, the polyphony mode trick opens some possibilities but that’s a lot of complexity just to get the original intended note/drum back from poly signal. Too bad PRs to VCV aren’t accepted but maybe this is my opportunity to try building by own fancy midi-gate.
I don’t quite understand this thread, but would my free sequencer also do this? It also has a companion module that will generate up to 8 gate triggers based on polyphonic cv and gate input. For doing drums with Seq++
Here’s a visualization with the current vs desired “note-on-only” behavior. In short, the drum midi controller sends a note-on followed by a note-off 10ms later, but if you start playing quickly, it’ll send the note-off’s earlier so that it can send the note-on of the next note; the result is that the note-off of the previous note happens pretty much exactly the same time as the note-on of the next note, and in this case MIDI-GATE just translates this into one long uninterrupted gate.
Until a solution is found.
but maybe this is my opportunity to try building by own fancy midi-gate.