Can't Kill the Timer

I am trying to set up a few presets so that on activation a one-shot timer is fired off which in turn carries out an outgoing action, in this case a simple CC#x message after a short delay.
But I need the timer to reset (be killed) when I activate the next preset. I have tried all sorts off things to kill the timer like ‘On deactivation of this preset’ and also ‘on activation of this preset’ but nothing seems to be killing it.
I have selected the correct timer in which to kill but it is just not happening. This resulst in the CC#x message being sent multiple times as expected.
Any help would be greatly appreciated.

Hi Most likely you are using a delay to start the timer so it may not be running. Timers cannot be killed unless they are running. Here is an excerpt from the use manual

Timer Initial Delay vs. Outgoing Action delay
Note that for starting a timer, you can specify an initial delay, and there is also the
possibility to specify an action delay (see Delaying Outgoing Actions). Those two delays
add up, but there is a big difference: by delaying the outgoing action, the timer will not
exist before the outgoing action delay has passed. So during that time you cannot kill or
override that timer! Consequently, you should avoid delaying an outgoing timer action,
and rather use the timer's (initial) delay

You will notice there are two type of delay.

  1. Initial delay of the timer
  2. Outgoing action delay

If you want to be able to kill the timer you should set the initial delay. If you set the outgoing action delay, the timer will not start until after a delay and cannot be killed.


Refer to page 58 of the user manual where this is explained. You might need to experiment with it in order to grasp the subtle difference.

Steve Caldwell
Bome Customer Care

Also available for paid consulting services:

Hi Steven,

As usual, thanks for the quick reply.
Here is a cut down version of my project. Maybe you could take a quick look at it and tell me what I am doing wrong.

Can’t Kill the timer.bmtp (5.9 KB)


This looks like it might be a bug as it doesn’t seem to match the documented behavior I will take a look at it. I put some log messages in the rules to see what is happening and also moved translator 2.3 to a new preset to make sure it wasn’t disabled (if preset 2 was disabled, the incoming action would not be realized.) I also messed around with the delay a bit.

1712420 - 2.0:1 Log Toggle MIDI Input Timer started with delay
1712920 - 3.0:1 Log Toggle MIDI Input Triggered
1712920 - 3.0:2 Log Deactivating Preset 2 should not happen
1713370 - 2.1:1 Log Toggle MIDI Input Timer Killed
1717920 - 2.2:1 Log Preset 2 Deactivated <---- This should not happen


Could you look at this to determine whether I am misinterpreting the documentation or whether this is indeed a bug. The only input aliases needed are
Roland Digital Piano and Launchpad Mini(3). Launchpad MINI 3 starts the timer “Toggle MIDI Input” by activating preset 2 with an initial 500ms delay. Roland Digital Piano should kill the running timer if anything is sent before the 500ms initial delay happens. He is using the initial delay and not the outgoing delay so the timer should be running

As you can see, I put Log statements in to make it easier to see what is happing with the word “Log” in the filter Box.

Can’t Kill the timer-sjc.bmtp (6.3 KB)

Steve Caldwell
Bome Customer Care

Also available for paid consulting services:

Thanks Steven. I have used many of these timers, but this one is being difficult.

This is working as designed… (and hopefully as documented!)

This starts the 500ms timer Toggle MIDI Input.

500ms later, translator 3.0 is triggered correctly. Note this is actually happening 500ms later, half a second (see the time stamp: 1712420 + 500 = 1712920).
It will deactivate preset 2, but with 5 seconds delay. Preset 2 will be deactivated at 1712920 + 5000 = 1717920.

Because the timer has already expired on its own, nothings happens here.

And here, 5 seconds after 3.0 got triggered, the preset is deactivated.

Now I think you’ve just underestimated how fast 500ms go by. In general, though, the approach here has a problem: the 5-second delay in translator 3.0 cannot be interrupted. So, once translator 3.0 got triggered, it will execute its outgoing action after 5 seconds no matter what. And that’s a classic race condition. Better would be to use the same timer, but a global variable to define the stage.
For example:

Outgoing: trigger timer "Toggle MIDI Input", one-shot, 500ms

Incoming: MIDI oo pp qq, on port Roland Digital Piano
  // kill switch
Outgoing: trigger timer "Toggle MIDI Input", one-shot, 0ms

Incoming: Timer "Toggle MIDI Input"
  if g0!=1 then exit rules, skip Outgoing Action
  // kill after 5000ms
Outgoing: trigger timer "Toggle MIDI Input", one-shot, 5000ms

3.1: **new translator**
Incoming: Timer "Toggle MIDI Input"
  if g0!=2 then exit rules, skip Outgoing Action
  // we're done
Outgoing: deactivate preset number 2

Like this, you can:

  1. trigger translator 2.0 and restart the cycle, no matter where in the cycle
  2. trigger translator 2.1 and kill the cycle, no matter where in the cycle

Again, it’s probably a good idea to tweak those numbers 500 and 5000.

1 Like


What do you mean by a 500ms timer?.
The timer triggers after 100ms on activation of preset 2. And I thought that is was meant to run until the outgoing action is executed in translator (2), 5 seconds after it is triggered by translator (0)
or it is ‘Killed’ by the Roland digital piano. No?

I’ve referred to the project file that Steve posted…

How do I kill a timer without having to type in all this?.

Florian is correct in that the timer had already tripped prior to killing it. Care must be taken to kill the timer prior to the time it tripped. The example below (with Logging) show that it is indeed working. I also changed the incoming for the intial trigger to be a note (just to make testing easier).

The key message is that to kill a timer, it must still be running and so you need to be sure of the timing of the kill timer translator in relation to the start delay of the timer.

Florian’s solution also works but indeed you need to add rules for that.

Can’t Kill the timer-sjca.bmtp (6.7 KB)

Steve Caldwell
Bome Customer Care

Also available for paid consulting services:

Thanks for all the help.
Can you please modify my originally posted project so that when I press a key on the Roland the timer is killed and thus preset 2 does not deactivate?. That would be great.

Well this is the way I would do it, without rules.

Translator 1.1 Deactivates preset to and then translator 1.2 Reactivates it. This ensures that 2.0 always trigger.

2.0 sets a timer to deactivate preset 2 if nothing happens within 5 seconds
2.1 kills the timer if there is any incoming MIDI message from your Roland.

With the way you had it the timing between the activation or the preset and the playing of the Roland was just too time critical. Now, you have a whole 5 second window to play the Roland and cancel the deactivation. I think this is what you were looking for.

Cant Kill Timer-sjc–2021-12-03.bmtp (6.2 KB)

Steve Caldwell
Bome Customer Care

Also available for paid consulting services:

Hi Steven,

Okay, so the ‘Initial Delay’ is the time in which the timer runs. Not the time before the timer fires.
Thanks for that.
By the way, In BMTP 1.9.0 the ‘Initial Delay’ is actually spelt ‘Inital Delay’. It is missing an I after the T.

Thanks again.

oh! thanks, will be fixed in the next revision. I’ve also found another instance of this typo :see_no_evil:

Maybe the ‘Initial Delay’ could be called something different to avoid future confusion.
Maybe ‘Timer Duration’ or something?. :thinking:

Here is the Google definition for initial:

existing or occurring at the beginning.
“our initial impression was favourable”

Hi Jesse, you’re absolutely right:
The “Initial” is confusing here.

It’s left over from the different types of timers, which have two distinct delays:

Will be fixed in the next version.