v0.3.3-a1 - Special Characters in Joystick Names?

This release changes the way joystick names are printed in the Sender application, to a way which should allow them to more reliably be copied into the config file if the name happens to contain unprintable characters which won't show up on the console.

How necessary this change is is yet to be seen.

v0.3.2 - Use VMC Tracker and OSC Parameter Setting by default

VNyan v1.1.17 has just released, which adds support for setting VNyan parameters via OSC messages. This feature simplifies setup and maintenance, as a node graph is no longer needed to allow the shift paddles and the pedals to move.

The old method of rotating the wheel via a parameter is now considered deprecated, and the default configuration and the Wiki instructions have been updated to focus on the use of a VMC tracker for this purpose.

This release also features a WIP implementation of the Rotational wheel technique, but it still has some issues that need to be worked out and I don't consider it ready to use.

The Viewer has not been changed, but has been attached for ease of access.

v0.3.1 - IK Fix

A fix for the hand IK, breaking when the character's body isn't facing forward.

The shoulder rotation was being applied twice. The perils of rolling your own IK.

The Viewer has not been changed, but has been attached for ease of access.

v0.3.0 - VMC Integration, OSC Input, and Selectable Initial Config

The headline feature of this version is the beginning of VMC integration in the Sender application, allowing for steering wheel input to be used to animate a 3D avatar!

The VMC integration allows the Sender to be used as a filter between a back-end motion capture software (e.g. VSeeFace) and a front-end avatar interface (e.g. VNyan) to allow for the avatar to be posed based on the position of the input device. Currently, the only type of anmation that is supported is a steering wheel, and the avatar's hands will currently be locked to the wheel (changing of the grip position based on the wheel's rotation to come in the future). In addition, blendshapes may be set based on axis input, which can be used (e.g. with VNyan node graphs) to drive other animation, such as the rotation of a steering wheel prop.

In addition, to continue to facilitate the use of this application in a dual-PC setup, the Sender can now additionally be configured to support receiving inputs via OSC as well. Since the VMC integration is tied to axis inputs, and VMC packets tend to be large and frequent, in order to reduce network traffic and prevent issues with oversized packets, the Sender can now receive inputs via OSC. This allows the Sender running the VMC integration to receive data from another instance of the Sender running on another PC.

At some point, the Sender will receive a UI to make it easier to configure, and at that point it will most likely assimilate the functionality of the Viewer, combining their powers into one single Remote Wheel application. But that's still in the future!

Additionally, due to the growing complexity of the configuration file and issues with the library that was being used to parse it, the configuration file format for the Sender has changed. Thus, old configuration files will no longer work! The general flow is the same (run the application to generate a default configuration file with documentation, then edit it), but old configuration files must be reworked. Hopefully I won't need to keep breaking config compatibility! Once a UI is created, this should hopefully become this a non-issue as the config will no longer need to be edited manually.

This version also adds a set of initial configurations for the Sender, rather than having a single default that is used. This allows the user to select an initial configuration that is tailored to their specific use case. This should help alleviate the configuration overload that comes from a heavily-documented default configuration, and give the user a config that is pretty close to what they want (with annotations about what will probably need to be changed).

While the overall functionality of the Viewer has not changed, its configuration file format has been updated to match that of the Sender, for consistency's sake.

v0.3.0 A5 - Unbundled Packet Support

Added support for receiving unbundled VMC packets.

Previously, a full VMC update would be sent every time a VMC packet was
received. This meant that if packet bundling was disabled in VSeeFace, the
Sender would inundate its output with an excessive number of packets,
possibly overloading it.

Now, a full VMC update will only be sent after an OK message is received.
The update will still be sent to the VMC output as a single bundle,
however, at least for now.

The Viewer application is unchanged, but is attached for ease of access.

v0.3.0 A4 - Choice of Initial Config

This adds a set of initial configurations for the Sender, rather than having a single default that is used. This allows the user to select an initial configuration that is tailored to their specific use case. This should help alleviate the configuration overload that comes from the old heavily-documented default configuration, and give the user a config that is pretty close to what they want (with annotations about what will probably need to be changed).

This also changes the controller axis configuration so that axis numbers are preferred, rather than names. Names are still allowed for backwards-compatibility purposes, but as the names don't always match the controller, they are considered deprecated.

The Viewer has not changed, but is attached for ease of access.

v0.3.0 A3 - VMC Trackers

This version adds an option to the VMC device configuration to tie the device's position to a VMC tracker. This can be useful with the new functionality in VNyan 1.0.19 that allows a prop's location to be linked to a VMC tracker's position.

The Viewer is unchanged, but is included for ease of access.

v0.3.0 A2 - Minor Fixes and Viewer TOML

Compared to v0.3.0-a2, this version has a few minor fixes to the Sender application:

• The OSC input range, if not specified, was supposed to be [0, 1], but was instead [0, 0], resulting in the value always being read as 0.
• The VMC report-interval, if not specified, was supposed to be to not report, but was instead being set to a default of 60 seconds.

The Viewer application has also been updated to use the same configuration format that the Sender now uses (TOML) for consistency purposes.

v0.3.0 A1 - VMC Integration and OSC Input

The headline feature of this version is the beginning of VMC integration in the Sender application, allowing for steering wheel input to be used to animate a 3D avatar!

The VMC integration allows the Sender to be used as a filter between a back-end motion capture software (e.g. VSeeFace) and a front-end avatar interface (e.g. VNyan) to allow for the avatar to be posed based on the position of the input device. Currently, the only type of anmation that is supported is a steering wheel, and the avatar's hands will currently be locked to the wheel (changing of the grip position based on the wheel's rotation to come in the future). In addition, blendshapes may be set based on axis input, which can be used (e.g. with VNyan node graphs) to drive other animation, such as the rotation of a steering wheel prop.

In addition, to continue to facilitate the use of this application in a dual-PC setup, the Sender can now additionally be configured to support receiving inputs via OSC as well. Since the VMC integration is tied to axis inputs, and VMC packets tend to be large and frequent, in order to reduce network traffic and prevent issues with oversized packets, the Sender can now receive inputs via OSC. This allows the Sender running the VMC integration to receive data from another instance of the Sender running on another PC.

At some point, the Sender will receive a UI to make it easier to configure, and at that point it will most likely assimilate the functionality of the Viewer, combining their powers into one single Remote Wheel application. But that's still in the future!

Finally, due to the growing complexity of the configuration file and issues with the library that was being used to parse it, the configuration file format for the Sender has changed. Thus, old configuration files will no longer work! The general flow is the same (run the application to generate a default configuration file with documentation, then edit it), but old configuration files must be reworked. Hopefully I won't need to keep breaking config compatibility!

The Viewer application has still not changed, but is attached as well for ease of access.

v0.2.0 - Button Inputs, Pre/Post-Bundle Messages, and Message Batching

This is a Sender-only update that adds the following features:

1. Button inputs may now be configured! See the default configuration for details; at the simplest, just specify button: # (with a number starting at 1) instead of axis: x. OSC messages must also be configured to be sent on-change, on-press, or on-release, whereas axis messages are always on-change (but this now must be specified manually).
2. Simultaneous input changes will be sent together in a single OSC bundle, which should make configurations with multiple inputs changing simultaneously (particularly axes) more efficient.
3. Pre/Post-Bundle messages may be specified. This allows an OSC message to be added at the beginning or end of every batch of OSC messages that are sent. This can reduce redundancy if every input needs to have an additional unchanging message added on, e.g. to indicate that changes should be applied.

Unfortunately, the addition of configuration for button inputs required the config file structure to be changed in a way that backwards-compatibility couldn't be maintained. The changes are minor, and a "backwards-compatibility" format could have been added such that existing configurations could still be used as-is until they are updated, but the program is young enough that I opted to avoid that maintenance burden and just break it. Hence, 0.2.0!

The Sender's default configuration file has also been updated with more thorough (maybe too thorough?) documentation on how it can be configured.

The Viewer has not functionally been altered, but its dependencies have been updated, and a copy of the binary is attached for ease of finding it anyway.