[Feature Suggestion] Delay Until Next MIDI Clock Quarter Note

[ambient]

Its currently possible in the MIDI editor to program a “Delay” of a fixed number of milli-seconds…

I would find it incredibly useful if I were also able to specify a delay untill the next MIDI clock quarter note comes around.

This would allow me to queue up actions that would be invoked exactly on the measure, and would compensate for my sloppy timing

There are potentially some nuaunces that I’ve not considered. I guess there are three MIDI clock states the MC8 might be in when an action is invoked.

1. No MIDI clock present
2. External MIDI clock
3. MIDI clock is being generated by the Morningstar controller.

I would assume if 1 then there would be no delay and subsequent actions get executed immediately.

And I’m not sure whether other timing options are possible, e.g. next half note, next bar (I don’t think MIDI clock provides this info though, its simply quarter notes and thats it).

Is this something that might potentially be implemented?

[Joe_K]

A similar request along those same lines:

[FR] Delaying / Quantizing Actions and MIDI Messages

I have a looper pedal that I control over MIDI with an MC6 MK2. I often wish the ending of my loops could have been quantized to the closest bar so that I would not have to be as diligent with hitting the switches on time to get a nice, on-time loop. If the MC6 could operate such that if I press to start recording and then press to stop recording before a full bar elapsed, then the MC6 will delay sending the stop recording signal from being sent out until the next nearest bar has been counted to…

[ambient]

Thank @Joe_K , I’m a YT subscriber of yours, and have my eye on the CLOCKstep

Yes that other FR is asking pretty much the same thing. Although it does specifically ask about delaying until the next bar, and as things stand at present, without the MC? being aware of time signatures or listening for a MIDI bar message, the only thing it knows about is the quarter note.

So I’d specifically be interested in hearing from @james whether the “delay until next quarter note” option is a possibility (and maybe the “delay until next bar” could come later).

[james]

Just had some time to think through this.

Might be possible as a new delay message type. If receiving external MIDI clock, a start message needs to be received in order to determine the starting point. If using the clock generated by the MCx, then the starting point is when the MIDI clock message type gets executed. Then we can calculate how long to delay until resuming the message execution.

During this delay, nothing else can be executed (i.e. controller will just be on hold until the delay ends). I don’t think we want to implement a queue system for this.

We can test this first, but not sure if feasible to implement yet.

[Joe_K]

Like you say, the only thing that makes a device aware of what a quarter note is, would be counting 24 pulses from the time when the clock pulses themselves start. Devices are free on their own to consider which of the pulses received or sent is actually the quarter note downbeat. If a person’s workflow always considers the instant the clock starts as the first quarter note beat, without deviation, or if a resync type of command was provided, then you can do something with that. Might be a cool feature. Sounds like you are saying that blocking is a bit of an issue you might have to face.

There’s still potential to cue to the next quarter note if the MC is made to respond to Bar Marker messages. The simple solution is to set a 1/4 time signature in the sending clock device. That way, the Bar Marker message it sends is actually every quarter note. This is something CLOCKstep supports.

If you ever decide to put a cue action associated with an incoming Bar Marker message, I will do a good video for that feature in MC! You’d be the first controller I know of to do it.

[Joe_K]

a Bar Marker can be sent on a 1/4 time signature, making 1 bar equivalent to 1 quarter note. That’s the most obvious solution I can think of that keeps everything going in perfect sync.

[Joe_K]

Just tell me to butt out if my thoughts are unwelcome. I’m excited about having this type of feature for my own MC with the looping that I do; I just happen to also be a guy who makes a clock pedal.

I was thinking about it a little more from your perspective, and if you do use a blocking delay in your code to time the remainder of the next quarter note, isn’t that going to be a problem for persisting the clock pulses? In other words, you might have success putting the controller into a delay state for the correct amount of time, but if it also means blocking the clock during that time, anything downstream in the MIDI signal path that depends on the clock will fall apart. That is unless your clock is able to run on its own thread of execution.

[james]

The blocking delay wont affect the MIDI Clock signals being sent from, or that are passed thru, the controller.

Eventually I think we can explore a queue system, where there will be an option to add messages to a queue, and then have something to trigger all the messages in the queue. It’s definitely doable, but I just need to make sure that there is enough resources in the hardware to support this and not introduce any limitations or issues.

[james]

I just looked further into the feasibility of this. I think it will only work well with a DAW or another MIDI Clock generator which sends MIDI clock and MIDI start messages, along with MIDI song position so we know where the counter left off if the clock is stopped.

If we just depend on MIDI clock messages alone, there’s too much variability which will probably make this feature useless. For example, if the clock stops for 1 second, and then starts again at a different tempo, where exactly are we at?

For internally generated clock, we can start the counter when the clock starts, but if the band isn’t playing to the same clock source, I don’t think this feature will be very accurate either.

[CSurieux]

Just insert a Bome Box in your set and program all these ‘exotic’ requirements on it.
Just my 2 cents.

[Joe_K]

I agree, offload the responsibility of combined clock and beat context onto another device. You know Clock itself is a simple concept, but combined with maintaining beat or song context, time signatures, etc, this stuff becomes resource hungry and non-trivial.

Avoid any need for tracking time for this purpose in MC altogether. Execute a message stack in response to markers received from another device, whether it be a DAW or a clock device. Markers can be any standard MIDI message.

A cueing feature like:
“Execute message stack upon receiving: [MIDI Start || MIDI Stop || Bar Marker || Note On (data) || CC (data)]”

That would be powerful without the need to even run a clock, timer or count internally.

I know we’ve talked about Bar Marker, and that is a simple, standard and effective way of communicating the start of a new bar between two devices, but there’s actually another way. The Metronome/click feature in CLOCKstep sends any MIDI Note the user wants in relation to time. It can send a note on the beat at every musical interval from Whole Note to 32nd Note (every triplet and dotted beat in between). It can send up to 3 different Notes: one that reflects the main pulse of the metronome (ie: 8th note), one for the accented note (ie: Quarter Note) and the top of the bar (ie: Whatever beat is the start of a new bar based on the currently configured Time Signature). This is all configurable.

And, of course, with a sequencer or DAW, you can send any sort of output message you like, at any point in time.

My thoughts on Song Position Pointer here is that it is a red herring for this specific purpose, but I’ll save those thoughts for another time if you become serious about exploring it.

[Joe_K]

@ambient

And I’m not sure whether other timing options are possible, e.g. next half note, next bar (I don’t think MIDI clock provides this info though, its simply quarter notes and thats it).

Oh, I forgot to mention this in my response. Tracking eighth notes or any other subdivision is no different than tracking quarter notes, because there’s actually nothing special that identifies a quarter note subdivision either. It’s simply that 24 pulses make up a Quarter Note, and that is always how MIDI Clock timing gets expressed. The clock data itself doesn’t contain any subdivision markers at all. It’s still up to the device to count the 24 pulses and know what is considered the start of the data to be able to land on the correct beat. Then simply count 12 pulses for an eighth note, 6 pulses for a 16th, etc.

I don’t know if that helps you in any way while you are exploring these ideas, just thought I’d help with the knowledge on the topic. There can be a misconception that there is more context to MIDI Clock data than there actually is, because we get to see devices doing all these cool things and we think possibly that it was provided in the MIDI spec. I can say first hand, that illusion gets shattered really fast when you dive in to the actual implementation details

[ambient]

@james appreciate you taking the time to give this some consideration and potentially implement

If we just depend on MIDI clock messages alone, there’s too much variability which will probably make this feature useless. For example, if the clock stops for 1 second, and then starts again at a different tempo, where exactly are we at?

Won’t this be the case for any device which tries to quantise to a MIDI clock? I’m thinking specifically of the looper pedals I have on my board (Boomerang & Microcosm, for exmaple) and how they handle these situations. I assume, in the absence of anything but MIDI clock messages, they just make their best guess about which pulse is the quarter note. So presumably 24th pulse since the first one, and if there is no clock for X ms (I guess the length of X is up for debate, but probably not that important), then you consider the clock stopped. If MIDI clock messages start arriving again after a stop, you just start counting pulses from zero again. Obviously I’m ignorant to how difficult this is to implement.

@Joe_K thanks for your insights, I’m defintely learning a lot about MIDI clock. Your intro videos on CLOCKstep are also a good learning experience

[ambient]

Just insert a Bome Box in your set and program all these ‘exotic’ requirements on it.
Just my 2 cents.

[CSurieux]

Ha Ha, but true in some way, for all those tricks you are requiring, especially real time, you need a tiger in the box, that was not the target of actual MCxx line of product, or I would not have the money to buy.
Anyway you have a nice stage outfit

[Joe_K]

I agree. An MC controller could keep track of the Quarter Notes like any other looper or sequencer, and should do so based on the presence of MIDI Start if the feature ever proceeds. Execution of Start could happen when the user has placed a Start command on an MC switch, or when received externally. Whether received externally or sent from within the MC Controller, it stands to reason that every device in the MIDI chain that’s also listening for the Start command will all have their count aligned. It’s been like that for decades.

Here’s more background.

Clock pulses merely keep devices from drifting away at their own rate, which happens over time to every device even when they are set to the same BPM internally. Clock isn’t really meant to do any more than that, which is why Clock data conveys no details such as quarter note markers or even BPM (devices don’t even know what the BPM a clock is sending at without calculating it themselves after sampling a few of the pulses).

Along with Clock, the other basic part to obtaining sync is MIDI Start (and Stop). When devices receive a Start command, they wait until the next Clock Pulse to reset their counts and begin doing whatever it is they’ve been programmed to do. This is what insures that every device considers the same pulse as the 1st one, even if Clock has already been running for a time. That also means if Clock is not already running when a Start command is received, the device should consider itself in a pending state. Devices are not supposed to simply execute start internally as fast as they can when the message is received. (some manufacturers have gotten this wrong, but most get it right).

You also see some devices implement a Resync feature to allow users direct control over realigning the count and restarting whatever it is the device does. Resync isn’t a MIDI standard command itself, it’s a batch of commands that effect an outcome.

Stop, of course, is the purview of the MIDI Stop command. The clock can even keep running when Stop is received; Stop isn’t actually a command to Stop the Clock, just as Start isn’t actually a command to Start the Clock. That gets a little muddied because many devices tightly couple Start/Stop with starting and stopping the Clock, which I’m not even saying is a problem, it makes sense in a lot of scenarios. I’m just saying that it leaves an impression that Start/Stop is specifically about controlling the presence of Clock, when it’s not.

What you are saying about Clock not being received for X ms for a device to consider things have Stopped is right on. If a device is in a state where it is dependent on Clock pulses, then the absence of Clock pulses gets treated as an implied Stop, even if no MIDI Stop command was received. It’s not uncommon for devices to have that kind of behavior in their programming.

I’ll just finish with this. In the implementation that I see, a general purpose MIDI Controller such as an MC can both implement its own count for cueing commands to a rhythmic interval, or it can rely on triggers/markers coming in externally for cueing (presumably the external device is being relied upon for the rhythmic context in that case). These aren’t mutually exclusive choices. You can always do one or the other or both and introduce them in separate releases. One choice (counting internally) depends on Clock and internal resources to keep track of that rhythmic context. The other choice (responding to triggers) doesn’t require anything other than putting commands in a pending state and waiting for the trigger to come in.

[CSurieux]

Seems you think people using the MCxx do not know this. Thanks for this lesson.
But do consider your are wrong.
RT is a very deep subject and big companies as Korg, Roland, Arturia, Waldorf, Elektron (not so huge), etc. , have troubles with some aspects of real time features, even the ones being highly multi-threaded in their core engines.
Further I would be prefering to let one of my keyboards or drum engine manage the tempo. and let it do what you want to be done in MCxx small engine which will soon overflow.
A midi controller is not an instrument or a sequencer.
Your ideal nuclear machine does not exist and will never in actual range of pricing.

Sorry, but I am ok with actual status for a midi controller and there is so much things to improve in this area that I don’t vote for what you suggest.

Try starting a kickstarter project.

[Joe_K]

Apologies for raising your aggression level by just discussing ideas.

[CSurieux]

Never too late to apology, but there was less agression in my words than in yours, and you know it.
My intentions were direct, manifestly not yours, reading this last comment.
The incident is closed on my side, there is small chance that you understood what I was answering to your requirements. The final word will stay in the hands of Morningstar.

[Joe_K]

You’re clearly offended by both the idea the OP presents and my support of it. I honestly don’t know why on either account.

First, the idea of a MIDI Controller that can cue commands based on a rhythmic interval is not that wild, though it is a challenge. Second, the idea of a MIDI Controller just being able to listen for an external trigger to issue commands is even less wild. I do support both ideas, and I did not mind that you do not.

James and I have also discussed this in private before seeing other people requesting it. And I know he wasn’t immediately sold on it, but hope springs eternal. I also want to point out, I originally linked this user with the request made by another user and that was all. In the other thread, James invited me into that conversation from out of nowhere because he already knew it was something that interests me. Whether he supports any of the ideas presented or not, I feel we’ve had very normal and productive communication on the topic, and I’m fine with it.

If I can’t say anything that convinces you my intentions are good, I guess there is nothing I can do about that. I’ve offered my first hand, practical experience that comes from actually developing a MIDI Clock Pedal which is also capable of cueing MIDI commands on a rhythmic interval. My contributions have been on point. The background information I provided was in the spirit of sharing knowledge on a slightly vague and ambiguous area of the MIDI spec. At least, in my experience.

Have a good day.