FFP Force Feedback Effect Improvements

[ej113]

See discussion #45

One change I want to highlight is this:

"Adapter compares the previous values of all MIDI parameters so that only parameters that have changed trigger a modification message to be sent over MIDI. This significantly reduces the number of messages that are sent to the FFP and may improve performance."

I chose to do this because the number of parameters that would potentially be updated by e.g. a Set Effect report has increased now that more parameters are supported. This would lead to an increase in the number of send..modify message pairs that would need to be forwarded even if nothing had changed. In practice it means that sometimes 10 or more USB messages are received, with no MIDI messages resulting. Either the USB message is a duplicate or the change is too small or not in a supported parameter. The risk is that if a MIDI message fails then the effect parameter may never be updated, so it could be less robust. It doesn't seem ideal to clog up the bandwidth with a lot of redundant messages, but not sure what a middle ground might be - send everything twice?? I didn't experience any problems I attributed to this in testing.

Draft Release Changelist:

Summary

The objective of this firmware update is to improve the force feedback capability for the Force Feedback Pro (FFP) to include the features that are supported only by all three of:
a) USB Device Class Definition for Physical Interface Devices (PID),
b) the FFP firmware, and
c) the "next generation" GameInput API.
It includes a collection of new features, bug fixes and workarounds of FFP limitations that cumulatively should improve compatibility with most games and make it more likely the effects will play as originally intended.

More details on the development here: #45

Tested so far with: Force Editor (fedit.exe), FSX, FS-Force for FSX, XPForce for FSX, SimFFB, Need for Speed III, Monster Truck Madness 2

Changes/New Features

• Fixes Subtle effects missing due to int overflow in CalcGain  #46 that caused some effects below 50% force to be halved and therefore imperceptible.
• Work around for an FFP bug that meant Constant forces could not be adjusted on the fly without suppressing the Envelope.
• Fix a bug that meant Constant forces could not be adjusted to negative values on the fly
• Device Gain supported (when available in software)
• All Device Control Commands supported (Enable/Disable, Pause/Continue, Stop All, Reset)
• Adapter tracks how many of each effect type are loaded to predict when FFP will reject an effect and report "Full" to host. This keeps Effect IDs in synch.
• Adapter compares the previous values of all MIDI parameters so that only parameters that have changed trigger a modification message to be sent over MIDI. This significantly reduces the number of messages that are sent to the FFP and may improve performance.
• All parameters are adjustable on the fly except effect type and periodic Phase.
• Report correct number of effects playable simultaneously to host (16).
• Effect Gain supported for all effect types (previously only constant and sine). This improves on FFP original drivers which did not allow Conditional effect gains.
• Offset and Magnitude apply for all Periodic effects (previously only Sine - other Periodics always played full strength)
• Fix implementation of Offset that caused erratic forces if Offset +/- Magnitude exceeded +/-100% force values.
• Envelopes for all Waveforms allow Attack and Fade levels to be greater than Magnitude.
• Full Ramp effect implementation. Ramp direction can be reversed on the fly (original FFP drivers did not support this)
• TriggerButton i.e. effects triggered in the FFP by a joystick button.
• Frequencies rounded to nearest integer Hz rather than floored.
• SampleRate supported for Ramps and Periodic effects. Previously always 100Hz.
• If SampleRate is set to "default" in USB it will be set to the greater of 100Hz or 4 x Effect Frequency. This allows higher frequency effects to be played without aliasing. Fixes Periodic effects don't work with all frequencies ("feature" of the joystick) #6
• FFP is initialised with auto spring centre on. This is different to previous behaviour but consistent with original drivers.
• [Debug] Allow new effects to be created in the adapter by simulating the USB CreateNewEffect report over USB serial port (when enabled).

Not supported

• Custom Forces - no known uses "in the wild". Dropped by latest GameInput API.
• Proprietary Microsoft SWForce effects (Wall, ROM, RawForce, VFX) - not supported by USB PID or game APIs.
• Periodic frequencies have been intentionally limited to 77Hz to avoid potential damage to components. Previously SampleRate was always 100Hz so max actual frequency was 50Hz. Original driver limits unknown. FFP can play up to 169Hz. See Periodic effects don't work with all frequencies ("feature" of the joystick) #6.

FFP Firmware Limitations and Bugs

• Some spring/damper/inertia parameters not supported - Only Coefficient and Offset implemented in FFP firmware
• LoopCount and StartDelay not implemented in FFP firmware. See feature request: support start delay parameter #33
• Periodic phases limited to 0,90,180,270 for Sine and 0,180 for Square,Triangle,Sawtooth. Not adjustable on the fly.
• TriggerButton implementation inconsistent with USB PID spec - Button release stops effect.
• TriggerRepeatInterval not implemented in FFP firmware.
• Low resolution of Periodic Frequency at high and low frequencies. See Periodic effects don't work with all frequencies ("feature" of the joystick) #6.
• Decreasing the Frequency of finite duration Periodic effects can cause effects to stop prematurely (FFP firmware bug)
• Max 10 waveforms and 2 of each type of Conditional effect can be loaded at any one time

Known/Possible Issues

• Wheel not playable even without Force Feedback
• It is possible that FFP devices do not all have the same firmware version, which might explain some of the apparent workarounds that were found not to be needed. The current version has only been tested with a #96755 device (no fan).
• (Not an issue but intended) FFP is now initialised with auto spring centre on, so it is now only possible to tell if force feedback is successfully activated by testing in an application that supports force feedback.

[ej113]

Not expecting you to review unless you want to tloimu, just adding you for awareness.