Ok. It is so then. Is suspect MS had fixed one user complaint in using 0xFn-MIDI-commands in the Wheel. There were complains from FFP users, that their MIDI musical instruments (e.g. a drum machine) went berserk when they played a game with FFP connected. Which is understandable as FFP used "musical commands" as its control commands. Now in the Wheel, looks like all effect control is now using only these 0xF1, 0xF2, 0xF3 etc. series commands that are considered as "non-musical commands". I would expect this to have helped life of the people with other MIDI-devices connected as they could now leave them on when playing a game.
So. To continue with the command analysis, we can safely assume that even the Wheel conforms to some form of MIDI messaging standard. This helps us to identify the commands and parameters from the binary mess.
You can now assume that all commands start with bytes that have high-bit on. I.e. all those 0xFx:es start a new command. E.g.
The initialization data is the one I previously posted, here is midi data for wheel init, effects and shutdown:
Code: Select all
f3 1d f1 0e 43 01 00 7d f1 7e 04 01 3e 4e f1 1c
45 01 3e 2f f1 0b 46 01 7d 00 f3 1d f1 10 40 00
7f 00 f3 6a
has multiple commands in it. I'll break them down on each line
Code: Select all
f1 0e 43 01 00 7d
f1 7e 04 01 3e 4e
f1 1c 45 01 3e 2f
f1 0b 46 01 7d 00
f1 10 40 00 7f 00
and as you can see, we always get the same amount of parameter bytes on each command, which is now comforting in that we are able to understand the "language" bit better. 0xF3 always has one byte parameter. 0xF1 has always 5 bytes of parameter data. 0xF2 has 2 bytes of parameters. Good to see some consistence there.
Then, to understand the parameter bytes, we know from MIDI that they cannot use the high bit. In order to represent numbers larger than 7-bits, they need to be spread to multiple parameter bytes and only using 7 bits from each byte. I.e. with two parameter bytes, we can express 14-bit numbers. In FFP, a "14-bit unsigned int" was calculated with formula simply
Value = Byte1 + Byte2 x 128
and so then a "14-bit signed integer" had values 0x7F00 = +max, and 0x0101 = -max.
I also noted, that in some 14-bit unsigned integer fields, 0x0000 marks infinity.
That "sine" sample (broken down into a command per line)
Code: Select all
f0 00 01 0a 15 20 02 7f 65 12 00 7f 00 40 7f 00 00 7f 65 12 7f 74 03 3e 00 f7
f1 01 0e 02 7f 7f
f2 2d 02
seems to match FFP's use of SysEx (0xF0..0xF7) for sending effect data, but with slightly different header "00 01 0a 15 20
" - which is expected as the header indicates the device manufacturer and product IDs for who the given SysEx-command is meant for. After the header, it looks like we have the wave form (byte) 0x02 = sine as in FFP. Then, I'll stop the guess work as the number of bytes won't match the FFP's format. But it is very much likely that as you change each parameter one by one and check what changes in the reports, you can construct a similar table for the Wheel's effects data as we have on the adapt-ffb-joy's MIDI-wiki-page for FFP. I would expect you to find very similar number formatting and some padding bytes there.
About that 0xF2-command. Looks like it controls the effects, as you already noted. First parameter byte seems to be the "command" (e.g. store, delete, start, stop...) and the second is likely to be the index number of the effect
. In all your samples, all effects were stored to index 2, but if you would send multiple effects simultaneously, you should see 0x03, 0x04 and so on there respectively. So, my guess is that the sequence "F2 2D 02" means "store the previously sent effect data to effect index 2". And that "stop"-sample "F2 3C 02" could be spelled out as "stop the effect at index 2".
And so on. Now you should find out what effect parameter of each wave form in FEdit is stored in what offset (and in what number type; uint7, int7, uint14, int14...) of the effect data in 0xF0-messages to the Wheel. Get ready for several hours of grinding with pure brute force
I hope the above (and the FFP's tables in wiki-page and in that ffb.c-source file) will shorten that task a bit as you should now know what to look for.
We are still missing at least one command. When you modify an effect on-fly, i.e. when it is already playing (e.g. amplitude or frequencey of a sine wave form effect), there should be yet a different command and its parameters for each effect parameter change. It is likely some form of "0xFn + some command + parameter ID/offset + value" and it may contain some padding to accommodate variable effect parameter sizes in a fixed size MIDI-command.