Minimum amount of time between two messages

StephaneDupont

2016-10-24 19:07:26

Hello,

I've already told that in a previous post, but it doesn't hurt to say it again: this software is wonderful, and I don't know how I could do my live setup without it! Thank you so much for it.

I'm playing guitar on stage, and I use a Line 6 Helix for my guitar effects, and also for sending MIDI signals to a computer with BOME MT installed (BOME MT sending signals into a DAW for playing virtual instruments, launching loops/samples, etc.)

The problem is sometimes when I press on a switch on the Helix (and I don't know if it's a software or hardware problem), instead of registering "Switch pressed" when I press on it (and "Switch released" when I release it), it registers quickly "Switch pressed/switch released/switch pressed" when I press on it. It's Helix fault, but if it's a hardware problem, I have to put it in repair, and that means several weeks without it, and I can't do that for now.

So I'm looking for solutions: would there be a way in BOME MT to filter messages so that there's a minimum amount of time between two messages?

Thank you,
Stéphane.

sjcaldwell

2016-10-24 19:27:15

Are you talking about potential switch bounce? If this is the case, perhaps you could set a timer on switch press at the same time disabling the translator. Then when the timer goes off, it re-enables the translator. Maybe just 100ms or so of the translator being disabled.

StephaneDupont

2016-10-24 20:21:55

Thank you for your answer!

Yes, it's not really a bounce, but kinda the same thing I think: I sometimes receive 2 messages (CC) instead of 1 because the footswitch register two times the "pressed" state.

I didn't know there's a timer in Bome MT and it could be used like that, great news!

So, what would be the better way to have every message coming on a specific port being protected against this bounce thing? I've got many translators, so would it be possible to have a message that "swallow" the message if it's too soon after another message? (without having to disable the many translators that would have to be disabled).

sjcaldwell

2016-10-24 20:42:26

Here is an example using keyboard escape key. Note to test this on Windows PC you need to disable keyboard repeat.

I also included text export

Code: Select all

Project: debounce
_____________________________________________________________
[x] Preset 0: New Preset

[x] Translator 0.0: Down
Incoming: Key down: Esc
Rules: gg=1
Outgoing: Text: D

[x] Translator 0.1: Settime Down
Incoming: Key down: Esc
Rules: 
Outgoing: One-shot timer "keydown": 100 ms delay

[x] Translator 0.2: Keydown time reached
Incoming: On timer "keydown"
Rules: gg=0
Outgoing: (none)

[x] Translator 0.3: Up
Incoming: Key up: Esc
Rules: if gg==1 then exit rules, skip Outgoing Action
Outgoing: Text: U
Note - Please change local variables in the sample to global as local will not likely work correctly
Attachments
debounce.bmtp
(1.27 KiB) Downloaded 117 times

StephaneDupont

2016-10-24 21:08:15

Thank you!

I understand the timer thing and the global variable thing, but how could I use that to "let through" the first incoming message, then swallow the others for X ms? (That's not the case in your preset)

StephaneDupont

2016-10-24 21:19:26

What I mean is: let's say I've got a translator that would have to swallow a MIDI message if a global variable is set to a certain value, it seems I can't have something like: "if g0==1 then check the box 'stop processing after executing this translator'".

All I can do is:

- "Skip outgoing action", but that will not prevent the MIDI message being processed by other translators I think
- "Disable processing": this will disable the processing of the first CC message if it's not been fully processed by other translators right?
- Do the opposite: swallow all messages, and recreate the MIDI message only if g0!=1, but that would need an additional Virtual Port if I'm not mistaken?

sjcaldwell

2016-10-24 21:49:22

Skip outgoing actions will not lose the incoming trigger on subsequent translators unless you check "swallow".

I think disable processing disables all translators on the specified preset.

You do not need to re-create a new midi message unless you set swallow and you want to use it later. If if you do, recreate one later, (like with a timer) you could send any output midi port.

StephaneDupont

2016-10-24 22:11:11

Yes, so that doesn't work.

So, there's no way to let through the first incoming message, then swallow the others for X ms?

sjcaldwell

2016-10-24 22:16:24

Yes you can, you will need to set the timer on release then swallow any further press relation actions until the timer goes off.

StephaneDupont

2016-10-24 22:20:47

... I understand the timer thing, the problem is how to swallow messages.

StephaneDupont

2016-10-24 22:36:08

OK, I found a way:

- I've got a first preset that is deactivated, with one translator inside that swallow any MIDI messages coming from the Helix
- I've got a second preset that when receiving a MIDI message from the Helix activate the first preset (so future message will be swallowed), then set a timer, that will on completion deactivate the first preset

I've got to test it yet, but it should work.

sjcaldwell

2016-10-24 22:48:15

OK, not tested because not connected to midi gear but if you are using say controller 10 on midi channel 1 where push down is value of 127 and release is value of 0 then this should be pretty close.
500 ms delay (1/2 second)

Note - Please double check the variables used are global. I may have used local variables which will not likely work.
Attachments
nodupe.bmtp
(1.69 KiB) Downloaded 105 times

sjcaldwell

2016-10-24 22:52:21

Glad to see you figured it out. Would like to see your bmtp file. I'm learning too.

StephaneDupont

2016-10-24 23:08:48

Will do when I will have tested it, but to answer your last post, I don't think you understand what my problem was. This wouldn't work, as:

- I need something to treat every incoming CC (not just one), and there's no "release" value transmitted for CC messages

- Even if there would be, the problem is that the Helix would send "127-0-127" on press, then "0" on release, so your solution wouldn't work

- I've got hundreds of translator that need to not process the second CC messages, I needed to find a solution that would allow that without changing thing (like adding a global variable condition) in these hundreds of translators.

Glad I think I found a way. Thank you for telling me about timers!

sjcaldwell

2016-10-24 23:28:06

OK, you could have a single translator set up to monitory (any cc) and set timer that way. This way it would disable any incoming cc for the specified time.

Of course any current operating translators would have to:

1) look at the global variable
2) swallow the incoming cc message
3) then only pass the message if the global variable is set to allow it.

So if you have hundreds of translators operating, that would be a lot of work.
If they all were under a single preset, however you could probably just disable the preset with all of the translators and then re-enable it when the timer goes off. Even at that you would want to disable any default routes in place on the project.

StephaneDupont

2016-10-24 23:53:30

They are not in a single preset, and my solution is better, as there's no need to do any change in the hundreds of translators.

Here's the bmtp file: (cleared of every preset that are not relevant to this)
Attachments
Test.bmtp
(1.93 KiB) Downloaded 127 times

StephaneDupont

2016-10-24 23:56:56

(the idea being to use two presets, as we can't activate/deactivate a single translator, but only presets)

sjcaldwell

2016-10-25 00:00:32

Right you are, just set the timer to eat all cc's and disable the preset. When the timer goes of re-enable the preset and start the timer again.

Thanks for sharing your solution! I'm sure others on this board will appreciate as well.

StephaneDupont

2016-10-25 00:02:56

Thank you!