Wanted: modified version of the clock app

Hello,

I’d like to use the MIDI-Pal as masterclock in my live setup, but it has an fault in its implementation, that makes it finally unusable: The clock stops when you hit stop. That is wrong.
The concept of MIDI-clock is: the clock tells the slaved device the tempo, and does that all the time - no matter whether the slaved devices should run or not. The start/stop commands tell the slaved devices when to start or to stop.
The problem becomes annoying as I use a MIDI-Clock to DIN-Sync converter and feed with the DIN-Sync various roland drum machines via a divider my modular system. As soon as the MIDI-Pal stops sending the clock, the DIN-Sync devices like the TR-808 are frozen, because they rely on the clock signal from the DIN-Sync. Same with the modular system, as the sequencers use the stop trigger as reset signal, and the reset would be executed with the next clock tick … which is missing now.

Long talk. short question:
Is there someone out there, who can change the clock app that way, that it does not stop sending clock?

Best regards
Florian

Yet that’s how Logic, Cubase or Ableton Live work…

I know that some devices keep the clock running no matter the play/stop state of the machine (like the Elektron machines), yet I fail to see the reason why you’d hit stop and not have things… well… stop. I mean if you hit stop then it’s because you want to stop all the stuff that is running, and if you have all the stuff that was previously playing not play anymore, what do you need the clock for? Mostly just wondering to be honest.

always running is probably useful to sync active always, and not have to wait after a start command AND THEN take time for the sync to catch up?

Just one question: is MIDI clock a global feature of a port or channel based ?
If it is a global feature of the protocol, it does make sense to continue on any means, simply if you use MIDI through and want the “slaved” device, running on another channel to continue playing.

The clock and the start/stop messages are global messages, they cannot be assigned to a specific channel.

So once a MIDI stop message has been sent, all devices downstream are going to step, and it’s not clear why they would need to continue receiving the clock.

Note that MIDI interfaces (including Yarns) usually ignore clock messages after having received a MIDI stop message. The processing of clock messages resumes only after a MIDI start or continue message has been received.

Bonjour Olivier,

First: thanks for thinking about this discontinued device.

Then: I originally did not want to discuss, whether a continuous clock makes sense or not. I am simply asking whether there is someone, who would modify this app for me (I would not mind to pay for it). Even better if this change would be helpful for others.

And finally - if we want to discuss the reasonability - then there are three reasons why the clock should be running:

1.) Theory: MIDI clock slaves do not use the MIDI-clock itself in a “hardware” sense (like for example the 16th-clock in a CD4017 based analogue sequencer), but they have to adapt their own internal tempo to the external tempo. The slave “gets used” to the tempo. If you stop the clock at 72 bpm, then change the tempo to 120 bpm, then the slave will be at the first ticks in the wrong tempo, because the adaption to the new tempo has to happen after the start command.
In fact: for many devices we don’t talk only about a few ticks, but for several beats or even bars. For example my electrix repeater needs two or three quarters to adopt the new tempo. The electro harmonix 2880 takes even longer and will fail in 50% to adopt to the new tempo at all. I never tried with ableton or reaper, but I assume that all appliances, which have to handle audio (especially with timestretching) will have this problem.

2.) Necessity: Some devices require clock. This affects mainly DIN-Sync and/or “analog” step-clock which is derived from midi-clock.
Setups for problem reproduction:
a) MIDI-Pal with clock app --MIDI–> Doepfer MSY2 --DIN-Sync–> TR-808 in external clock mode.
If the MIDI-Pal stops, then the TR-808 is frozen. You cannot change patterns, you cannot change to write mode, nothing…
b) MIDI-Pal with clock app --MIDI–> MIDI-to-ClockTrigger Interface --16th trigger and start / stop triggers --> sequencer like Doepfer A-155 or A-157 or Make Noise Brains/Pressurepoints. The stop-trigger is connected to the reset input of the sequencer.
The stop/reset enables the reset, and the next clock tick will make the sequencer jump to the last step. So the first clock tick after the start would advance to the first step of the sequence. But with the clock missing in stop mode, this jump to the last step won’t happen while stop mode, but instead the sequencer will jump to the last step with the first clock tick after start. So the sequence always will hang one step behind.
If I remember right the same happens with the Intellijel Metropolis (but I don’t have it here at the moment, to test it).

3.) Rules: There is no detailled regulation that the clock MUST run while stop mode, but the MIDI Spec 1.0 is aware, that this may be required, due to the reasons I mentioned in #1.
Quote from page 36 of the MIDI spec, Version from February 1990: “…If Timing Clocks (F8H) are sent during idle time they should be sent at thecurrent tempo setting of the transmitter even while it is not playing. Receivers which are slaved to incoming Real Time messages (MIDI Sync mode) can thus phase lock their internal clocks while waiting for Start (FAH) or Continue (FBH) command. […]”

So once again: I don’t call the stopped clock as a bug, it is a change request :slight_smile:

Best regards
Florian

Actually this is a very interesting discussion imho. so thanks for the detailed sum up of your reasons behind the request, it all makes a lot of sense indeed.
I’m not in the position to assist you with any modification of the firmware though so this is all I can say.

I had a look at the code. It’s going to take more time to find a working midipal board and AVR programmer than to actually code the change :confused:

Which version of the firmware (other apps) do you use? Do you need the high resolution version of the clock? SH or step seq?

Bonjour Olivier,

c’est très gentil! Merci beaucoup!

I run firmware version 1.2, midipal_stdclock_shseq_tanpura.syx

I personally do not need the hiresolution clock.

If you want to (and if the effort isn’t too big), then I’d suggest to add an additional parameter to the clock app (or both apps) for reasons of backward compatibility:
cont clk = continuous clock
possible values:
true = clock is provided all the time
false = clock is provided only in running mode

If you need my MIDI-pal let me know :wink:

Cordialment
Florian

So… 5 mins to code the change, 10 mins to get a test setup, 3 hours to try reducing the code size so that the change can be kept in the main codebase and everything can continue building as normal.

midipal.syx.zip (22.3 KB)

2 Likes

So awesome, this is great Olivier!

That is great! Many many thanks! I tested it immediately with my electrix repeater -> works fine now.

5 mins to code the change,
10 mins to get a test setup,
3 hours to try reducing the code size

:-)))
Was coding ever different?

Encore: Merci beaucoup!

Florian