Broken router rules with patch: keyword

[tizfra]

Hi,
with a older version of squishbox (0.7.15) I've wrote some router rules that helps me to navigate thru patches with button on my alesis vortex wireless 2.
Now, with the last version of software (0.8.2) that rules doesn't work anymore.
The rules are:
- {type: cc, par1: 44, par2: 1-10=0, patch: select}
- {type: cc, par1: 44, par2: 11-20=7, patch: select}
- {type: cc, par1: 44, par2: 21-30=8, patch: select}
- {type: cc, par1: 21, par2: 1-127, patch: -1}
- {type: cc, par1: 22, par2: 1-127, patch: 1}

@albedozero can you help me?
Thank you in advice

[albedozero]

Greetings, Sorry about that - I did tweak patch: rules a bit back in v0.7.13 (e0b78f2) (not sure why it would have still worked for you in 0.7.15, but oh well). TLDR you put a plus or minus *after* the number to increment or decrement. I knew this might break things for some people, but now you can have a rule that selects a specific patch by number, or even name, in addition to the old functionality.

[albedozero]

I'm playing from fluidpatcher on Windows 10 notebook, but I think there isn't any difference between fluidpatcher on Windows and squishbox. Is that right?

That's correct

[albedozero]

New release is here

[tizfra]

Thanks for the new release, this rule - {type: cc, par1: 21, par2: 1-10, patch: 1-} now works perfectly.
Can you help me to find where is the problem in this other router rule - {type: cc, par1: 22, par2: 1, patch: 0}?

When I send CC22=1, I want to select the patch 0, but with this rule I don't see 22=1 in midi monitor, I see all the other values, but not the 1.
I've also done the test with MIDI-OX and a virtual midi cable, to see that I send the value I want.

[albedozero]

This was a different but related bug, now fixed by #96 and updated in the latest release. Also, I decided that patch numbers should start with 1, rather than zero, so that they match what is shown on the squishbox display.

[tizfra]

Tested and now works perfectly.

Thanks for the help