Fix bad router behaviour.

[jjceresa]

Actually, while passing an input event through a rule, if chan, par1, par2 fields are out of range they are silently bounded to internal valid limit. This leads to an incorrect MIDI message forwarded to the router output which could interfere with previous message forwarded on the same MIDI channel.

To fix this issue, if chan, par1, par2 fields are out of range than the rule is simply skipped.

[derselbst]

In this case, clamping the values seems slightly better than silently skipping the rule, IMO.

[jjceresa]

clamping the values seems slightly better than silently skipping the rule, IMO.

The rule-change-value can be outside MIDI values valid ranges.
1)If the rule-changed-value was not clamped and passed to the synth, the synth will ignore the MIDI event because it contains invalid values. This is a predictible correct behaviour.

2)Clamping the rule-changed-value produces a valid MIDI value but a value not intended by the rule.
This clamping is equivalent to an internal rule not predictible and not under user control.
Then when this clamped value is passed to the synth this produces a MIDI message y that could interfere with a MIDI message x previously received (on the same MIDI channel). Example:

• MIDI message x: ccx on channel 15 passed not modified to the synth.
• MIDI message y: ccx on channel 31 is out of range and clamped to channel 15. This will break MIDI message x already received by the synth.

To get the same behaviour than (1), this MIDI message y for the current rule should not be passed to the synth. Ignoring the message is an audible behaviour more predictible. That could help the user to investigate what is wrong in the router rules.

[derselbst]

I'm not sure. @mawe42 Do you have an opinion?

[mawe42]

I think I agree with JJC, message values outside of the valid ranges could have any meaning. Simply clamping them is probably not any better than ignoring them, from a musical perspective. After all, we have no idea why they are out of range... bit flip, client error, deliberate value of another software or synth? Ignoring them is much more predictable and easier to understand, in my opinion.

[derselbst]

Ok, then pls elaborate on the documentation of the return value. E.g.

* @return #FLUID_OK if all rules were applied successfully, #FLUID_FAILED if an error occurred while applying a rule or (since 2.2.2) a parameter was out-of-range after the rule had been applied.

[jjceresa]

Simply clamping them is probably not any better than ignoring them, from a musical perspective.
Ignoring them is much more predictable and easier to understand.

In fact values (chan, par1,par2) that requires ignored vs clamped are dependent of the MIDI type of incoming MIDI event.
I propose the following adjustment that allows full benefice of the rule (clamped) and avoid MIDI messages conflicts at the synth input(ignored):

• chan value: ignored regardless of the event type
• par1: ignored for PROG_CHANGE, clamped otherwise.
• par2: clamped regardless of the event type.
  Opinions ?

[derselbst]

Sounds good to me.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
0.0% Duplication

[jjceresa]

Thanks for correction on my crappy comments ;).

[derselbst]

No problem :)