The ability to shift the notes into place in real time
Useful on laggy iPads and useful on tired performanves
Even if most people don’t use it, it’s still there for those who might.
That’s a great feature request and exactly what I also wanted to ask for.
That’s very helpful for playing an arpeggiator on synth A to accompany a drum track coming from synth B. It’s always difficult to start the arpeggiator pattern in perfect sync to that beat, even if the arp has the same BPM than the drum track.
The MIDI real-time quantizer shall snap notes to a beat grid, defined as 1, 1/2, 1/4, 1/8 or 1/16 of a 4/4 measure.
That would be a very useful feature. Some Arpeggiators like „BlueArp“ have such function build in. Also some synthesizers like Nordlead or Sequential OB-6.
I strongly need such a feature and really beg the developers to integrate it in a close future firmware update.
Thank you!
Yes, we have this in our list of todo. 
We’re making rounds on improving various areas of Midihub and the Editor, we’ll be implementing new pipes too, stay tuned.
5 Likes
Let’s gooooooooooooooooooooo!
1 Like
YES! Please do this!
I am using clock dividers and ratcheting multipliers in eurorack to mangle trigger / gate signals into complex evolving voltages (pitch/velocity CV information by the summed voltage of overlapping gates and multiple timings of such) - and have ideas for an algorithmic means to reverse this process and bring it all back to the original gate signal / tempo…
step 1 Gate / Trigger
step 2a signal divisions into 7 “lanes” of CV trigger patches into selectable base 2 exponential, integer or prime integer steps, each new trigger in a separate CV channel - useful to trigger drums or sidechain additional control
step 2b ratchet / multiply the triggers within lanes / delays on any of these timing lanes
step 3a ADD triggers by summing mixer so that voltage of gates and triggers rises and falls depending on which gate/trigger voltage lanes are summed effectively creating an additional pitch or velocity modulation in CV voltage similar to S&H methodology
step 3b logic processing “or combination” - to maintain voltage a simple “or” logical circuit brings all of these lanes back into one timing lane matching the original trigger with the additional triggers as modulated in steps 2a/2b sidechains
step 5 bring the beat with pitch / velocity sidechain voltage into midi land and process with your tools
step 6 use midihub to deconstruct and simplify this cacophony of pitch, velocity, and timing - for instance into a simple house beat by applying algorithms to latch timings of the generated signal to a selectable grid of timing - by choosing that timing scale and mapping a fader or knob…
Sort of like a “Groove Quantize” feature in a typical DAW, but where we have an ability to organize what seems random by applying user-configurable algorithms to trigger/gate, pitch scales/velocity instead of humanizing a precisely quantized beat.
This totally turned into an onslaught of brainstorming - my ability to communicate my imagination is quite limited by my vocabulary.
MBK
1 Like
Please, let’s NOT define this feature in terms of a 4/4 measure. We shouldn’t assume that music is in 4/4. A lot of it isn’t, and it’s fairly infuriating to find time signature assumptions embedded in devices and unable to be changed. Here’s an illustration of the problem:
Let’s say you define your quantization as 1 bar of 4/4. That’s 96 clock ticks. As long as the music is 4/4 this works. But if you are in let’s say 3/4, a bar is now 72 clock ticks, and the quantization setting now doesn’t line up. In fact any time signature other than 4/4 or 2/4 will drift in and out of sync with this “bar” quantization setting.
OK, you might say, do it in terms of beats (1/4 notes, which are 24 clock ticks). 3/4, for instance, would be 3 beats for a bar quantization. But let’s say the music is now in 9/8. How many beats is that? 4.5!
A better solution is to define it in terms of 16th notes. With a range of 1-128 that would allow quantization for any value from a 16th note to 8 bars of 4/4.
This would leave out time signatures like 17/32, though. The most inclusive solution would be to define quantization in terms of ticks and a multiplier - that is, a x6 multiplier would set it in 16th notes, a x3 in 32nd notes, x12 in 8th notes - which would accommodate any time signature, and would allow users to tradeoff granularity for range if very long quantization intervals are desired. You could even quantize in triplets if you wanted (e.g. x9 for 8th note triplets).
A caveat. Some devices send out clock continuously. If the Midihub just counts clocks and quantizes based on that, then depending on when the sequence is started, the quantize point could be on any tick within the quantize interval, and most likely wouldn’t line up with the actual beat division. To counter that, start counting ticks when a midi start message is received, and stop when a midi stop message is received.
2 Likes
I would say, yes, let’s define this feature based on 4/4 measure because that’s the most common beat measure in the world. But beside of this, why shouldn’t it be free configurable to any measure you would like to see?
Because, for example if I want the notes quantized to be delayed to the beginning of my bar, means they are not 1/16, not 1/8, not 1/4, not 1/2, but exactly 1.
So when ever I press a chord, the Arpeggiator is started on the 1 of a 4/4 measure, or in your case on what ever measure you have configured.
There are big problems with this, as I already explained:
One, if you can’t define the quantize in small units (16th notes as least), time signatures other than 4/4 can’t be accommodated. This is exactly why your spec of “The MIDI real-time quantizer shall snap notes to a beat grid, defined as 1, 1/2, 1/4, 1/8 or 1/16 of a 4/4 measure” needs to be modified.
Midi does not know where the bar lines are. That information is not in the midi stream. Which means that, if you assume a 4/4 bar (96 clock ticks), any other signature is the wrong number of ticks, and it won’t consistently clock to the bar line.
For your usecase of always being in 4/4, and let’s say the quantize is set in 16th notes like my “better” solution above: in that case, just set 16, and you have a one bar quantize, just as you wanted. I don’t see the objection. It’s simpler than having to define a bar length as a separate operation, and having extra controls mapped. And even if you did that, how would you define 1/2 a bar if you were in 3/8? Now we have the midihub having to calculate 16th notes anyway (1/2 of 3/8 is 3/16), potentially slowing things down, and for no reason.
2 Likes
Maybe there is just a misunderstanding.
In this picture I have summarized the basic theory of the algorithm I am thinking about.
You have to configure in which beat measure you want to play. For example 4/4 or 3/4 or any other measure you can think of.
The algorith is counting the MIDI clock messages from the MIDI start message on. There are 24 messages for a quarter note and 6 messages for a sixteenth note.
So - if you have configured a 4/4 measure bar, you have 96 MIDI clock messages for a whole bar.
And if you have configured a 3/4 measure bar, you have 72 MIDI clock messages for a whole bar.
Now you can also configure your quantization invervall e.g. 1, 1/2, 1/4, 1/8, 1/16, but also 6/16 or 3/8. You should be absolutely free in defining your quantization interval.
And then the notes you play are delayed until their time in the defined grid has come.
In a 3/4 measure bar, of course, there is no 1/2, because not every quantization inverval is matching to the chosen beat measure, that’s clear. There should be a calculation method behind, that blocks certain input variants of quantization intverals, depending on the chosen beat measure.
Have a nice day.
Thank you, I know what the algorithm is. Defining bars seems like an overly complicated way of implementing quantization. Like I tried to say in my previous reply, why have a separate variable that defines the time signature? Just define the quantization interval in 16th notes, and you can set it to one bar of 4/4, or 1/2 a bar or whatever, very easily. Just set it to 16 16th notes for a bar, or 8 for a half bar, and so on. Or 32 for 2 bars, if you want. This gives a very use range of a 16th note to several bars in 1-128. One variable, one 7 bit CC message, and it’s taken care of.
Similarly, for 3/4 set 12 for a bar, 6 for a 1/2 bar and so on. Please note, for a 3/4 measure (72 clock ticks) there is a 1/2. 1/2 of a 3/4 measure is 3/8, or 36 clock ticks. So let’s not block that interval. Some intervals won’t divide out to an integer number of clock ticks of course, but any x/4, 8 or 16 will. 1/2 of a 16 note is 3 clock ticks, then multiply by the numerator, and you’re there.
But really, defining quantization in terms of bars and then making the midihub make all the calculations just seems pointless and overly complicated. I am glad to see that you’ve backed off the idea of defining everything in terms of 4/4 though.
1 Like
Defining the quantization interval in steps of 1/16 (6 MIDI time clock messages) w/o defining the bar/time measure seems to be a good idea, I think.
My plan is do develop the algorithm at the MIDIboy by myself, since I am software development expert, able to write a C++ code as well as C#, VB.net, Java, SQL, and various PLC dialects.
I have developed, for example, this Arduino based sound reactive LED pixel matrix screen.
Here I provide the simple schematics of a model for the MIDI realtime quantize algorithm, that I am going to implement for the MIDIboy.
2 Likes
That’s great. A few suggestions:
Some devices send clock when stopped. So, when the stop message is received, the clock message counter should reset, but also stop counting.
For a Continue message, the counter should resume counting and not be cleared.
Allow some other messages to be quantized. Program and Bank change message quantization would be really useful. Quantizing Sysex, OTOH, would be a bad idea!
A triplets option, which when selected, would use a unit of 4 ticks (16th note triplets) instead of 16th notes. This isn’t needed to support time signatures, but if this feature is also intended for an arp or MPC-style note repeat, it’s important.
2 Likes
Hi all! So… I have bought a midihub and it arrived here safely today, thank you! Great product! It’s all good so far however I was really reallllly hoping that I could implement a feature such as this. I’ve been making music with several apps that do this, kind of used to it and I like the idea so that if I record a multitrack session then I know there should be less editing and everything is perfectly in sync. Is it something that you did go and implement or are you still working on? I have updated it to the latest firmware and I’m just getting my head into it. I don’t see a clear way to achieve this though. I tried using the delay node, tested it and I can see it syncs with the clock. Also with the repeater, which is almost there but well… I don’t want it to repeat lol. Am I missing something? Surely it should be possible no? I don’t do modular but I nearly did just to get the Hermod module that can do this but I thought surely the Midihub can do realtime sync 
1 Like
Still unsure if it’s possible, I’m doing a lot of trying to figure it out Would the ‘sync delay’ pipe combined with something else work? I’m not entirely sure what the ‘sync delay’ does but it certainly sounds like it could be ‘realtime timing quantize’??
Sync delay only affects the clock. There isn’t a great way to do time correction at the moment but Giedrius said it’s on the todo list so that’ll likely change in the future.
1 Like
The key issue to my mind, Steve, is “How does Midihub know where the ‘beat’ is?” (to ‘snap’ to!)
There are 24 Clocks to a beat and Clocks are all that Midihub currently knows in terms of timing:
It has no idea of which Clock the down-beat is on.
So adding this sort of functionality (aligning the “quantise grid” with some sort of trigger like Start|Continue or SPPointer) likely comes alongside introducing a whole bunch of other pipes like Sequencer, Groove Template, Rhythm Pattern, Beat Transform|Trigger, etc. to introduce users to the implications of the new capabilities…
…All very cool but probably not a minor update!
1 Like
Possibly yes, I’m not entirely sure how it would work to be honest. I know other things like Squarp Hermod will just delay the note until whatever division of the clock. I have experimented trying to do it with Midihub and I’ve kind of been able to do it with the ‘repeater’ pipe but… the notes obviously keep repeating though but it does sync to incoming midi clock from my sequencer. Or like the same as the arpeggiator will sync with midi clock either coming in or by setting up a clock in midihub. You can then change the signature divisions. So I imagine it would be quite easy to have basically either the repeater or the arpeggiator and simply have the option to set the repeats to 0 and the end of the notes don’t sync so you can still sustain a chord etc.