Some notes on the current state of development on the Femulator firmware and software.
Volumes, Filters, and Encoder
These analog-style controls need special treatment. Firmware needs to handle the “device-attached” scenario and the software needs to handle soft-takeover. The endian of 16-bit fields also requires special attention.
Hardware Considerations
When the Femulator hardware is attached to the system, the NIHardwareService uses a control transfer to request an input report to determine the current state of the hardware. There is no soft-takeover mechanism for attaching new hardware, which means any changes made to the controls in the UI will be overridden. The firmware needs to set initial, reasonable values for the input report, otherwise everything will be set at the lowest setting. This is done by setting the initial input report to pass values that correspond to the middle positions of each control.
Software Considerations
When Play mode is started by the Femulator software, soft-takeover is in effect, so changes to the controls made in software may not have an immediate effect if the state of the Femulator hardware does not match the state of the UI, which would be the case if the user has adjusted a control using the mouse. Because of the soft-takeover, the Femulator need not save or load its state.
Endian Considerations
Analog controls use 12-bit values to represent position, which requires two bytes in HID reports. Because the HID report is a byte-stream, the LSB comes before the MSB. For example, the maximum value for a 12-bit analog control is (2^12)-1 = 4095 = 0x07FF, which should appear in the report bytestream as 0xFF, 0x07. This is detailed in the Native Instruments F1 HID Protocol Analysis document and requires slightly different treatment in C/avr-libc/LUFA than in Java.
Deck Selection
When Traktor starts, it issues HID output reports to the F1 to set the LCD and pad states, which display which Remix Deck the F1 is currently controlling. It will continue to issue output reports (at an alarming rate) until a deck is selected. To select a deck using the F1, the encoder knob is turned. Once this is done, the output reports cease until Traktor has a status update.
Currently, the encoder knob is set to the middle position by the Femulator software when entering Play mode. Perhaps this should be user-configurable? Should Play Mode simulate some twiddling, by decreasing the value and then increasing it again?
Firmware will respond with the encoder in the mid position when first attached to the system and queried via Control Transfer. There is not soft takeover.
Volume and Filters
When the Femulator starts up, the F1 Input report is all zeros. This is equivalent to turning down all volume faders and all filter knobs. Ultimately the input report state should be saved when exiting Play Mode and restored on the next run.
Currently, the volume and filters are set to the mid-point by the Femulator software when entering Play mode. Note that soft-takeover seems to be in effect, so if the volume and faders are adjusted in the UI (using the mouse), the values will not be overwritten when Femulator enters Play mode.
When the femulator device is first attached to the system, an input report is generated via control request. This initial value has been coded in firmware to set all volumes and filters to the mid position. There is no soft takover when the device is attached, so all controls are reset regardless of any UI adjustments.
USBLyzer
When capturing, input reports do not seem to show up until the 3rd or 4th output report has been sent. While this may be alarming, Traktor responds correctly to all input reports.
API and Applications
Currently built into the Femulator software is a Netbeans module called F1API. It contains two packages, com.angryelectron.femulator.f1api, which is the controller for the GUI, and com.angryelectron.libf1, which is the package that interfaces via HID with the Femulator hardware. They need to be separated to create an independent API that will allow other applications to interface with the Femulator hardware.
The current Femulator application is rather basic, and doesn’t support all the styles of mapping that Traktor does. It seems redundant to create yet another mapping tool, when good ones already exist. It would be nice to leverage a tool like Bome or similar.
Alternatively, the independent femulator API could be used to develop controller-specific applications, the most basic of which could be a Launchpad application that simply maps each of the Launchpad’s 64 buttons to the 64 slots in the Remix Decks.
Roll-Your-Own Controller
Further additions to the firmware could support the generation of HID input reports in response to serial input for boards like the Arduino UNO. This would allow users to build their own hardware controllers that, through an Arduino sketch, were capable of controlling Traktor’s remix decks.