IRT transpose values not correctly handled

[maks]

Previous fix to IRT in #818 incorrectly handled transpose down (values above 0x80) and also had typo where decimal 80 instead of 0x80 value was used as the transpose up/down break point.

[democloid]

Ok, I'm, honestly confused about this one. Per #818 The manual is quite specific on how IRT and its transpose feature should work in tables but it doesn't seem to work in automation tables.
I honestly don't see it. Where is the documentation that values over 0x80 are negative?

Also the bound checks seem pretty bad, we reduce an octave until we are on a valid octave? is that what we want?

note is an int, so where is the lower bound check on this one?

[maks]

Ok, I'm, honestly confused about this one. Per #818 The manual is quite specific on how IRT and its transpose feature should work in tables but it doesn't seem to work in automation tables. I
honestly don't see it.

I think you put that here accidentally? as I think you are referring to #1381 PR not this one?

Where is the documentation that values over 0x80 are negative?

Well thats a good point that should be explicitly added to the IRT cmd docs but the IRT cmd docs do quite clearly say:
"...So a table with IRT 0001 will keep going a semitone up. Great for dubby echoes :)"

Now how would you expect to be able to go a semitone (or more) down? Sure it doesnt say it for this command but other commands do explicitly document using negative values,
eg. for LEG:
"bb values are relative: 00-7F are up, 80-FF are down, expressed in semi-tones"

eg.LOF:
"LOF 0001 adds one to both values, LOF FFFF removes one (so values > 0x800 moves the loop backward)"

and of course most directly related to this, the transpose value on Chain screen uses 0xFF and lower to 0x80 to mean transpose down.

Also the bound checks seem pretty bad, we reduce an octave until we are on a valid octave? is that what we want?

note is an int, so where is the lower bound check on this one?

Good point, yes I'll add bounds checks 👍🏻