"Sticky" Swallow

Bome Products
1

I've found that swallow is not "sticky".

If one rule exits normally with swallow, but then a second (more general) rule matches the input as well, then THAT second rule requires swallow as well.

From the manual it seems that swallow was supposed to be sticky - as it mentiones "at least" instead of "all":

Page 36:
So, when an incoming MIDI message matches at least one Incoming MIDI trigger, the message will not be sent to the MIDI Router

Annexed a small demo. There are two equal rules, one with swallow, another without.

# with rule 3 OFF:
10073701 - MIDI IN [DDJ-1000]: 91 64 7F
10074237 - MIDI IN [DDJ-1000]: 91 64 00

with rule 3 ON:


10081174 - MIDI IN [DDJ-1000]: 91 64 7F

10081174 - MIDI OUT [Bome MIDI Translator 1 Virtual Out]: 91 64 7F <<<<<<<<<<

10082712 - MIDI IN [DDJ-1000]: 91 64 00


Attachments:

1603652237665_log.txt

1603652237669_swallow-example.bmtp
2

Hi Pedro,

Here is how swallow works.

If you don't have any thru paths, no worry. Nothing goes through unless it passes the rules.

If Swallow is set, the following must be true for the message to be swallowed:

  • The output action needs to be NONE or
  • The output action needs to execute

For example, if you have a rule like this:

if pp!=0 then exit rules, skip outgoing action AND swallow is set AND there is a default thru path, the original message will still go to the thru path.

In this case, you need to either remove the thru path or add another translator with no outgoing action to swallow the original message.

By default, each translator acts stand alone so if you have multiple translators with the same incoming trigger, each translator will need to have swallow set with the above conditions. However if you have two translators and want to stop processing after the first (with our without swallow set), you can check the box labeled "Stop processing after executing this translator" in which case, later translators with the same trigger will be ignored.

For this reason, I typically do not use THRU paths that often as I like to avoid surprises like this. Either that or always put a translator at the end of the list that has no outgoing action with swallow set.

 

I hope this clears things up.

 

Steve Caldwell
Bome Customer Care

Also available for paid consulting services: bome@sniz.biz

3

Thanks for the clarification.

Doing “stop processing after this rule” and moving the swallow rules as late as possible are reasonable workarounds.

The only issue, then, is the still surprising nature of the current implementation - hence my request.

I also believe that it contradicts page 36 of the manual.

Thanks

4

Hi Pedro,

It works as designed however maybe the reference in the manual could be clearer. It relates to each translator and not for swallow for "all translators" that meet the incoming criteria.

I will be happy, however to discuss with Florian. This was a point of confusion for me some time back and once I understood the design, it was clear why it was set up that way. Doing it any other way would have other side affects so I believe this is the best way to handle it.

 

Steve Caldwell
Bome Customer Care

Also available for paid consulting services: bome@sniz.biz

5

Previously i understood completelly the design. But after a while it still tricked me again. Hence my comment that this is surprising (but probably necessary) design

6

I agree that it is somewhat surprising and contradicts the user manual. We’ll look into it. We shouldn’t really change the implementation, because probably many project files are relying on the current behavior. But fixing the user manual is important in any case. Thanks for reporting!