No not that kind, my therapist handles that.
Need help with VDJ 6 and the SCS 3 system.
Their site says that jog wheels and encoders will need a device defintion.
here's part of the explanation. the rest is in their forums.

The Controller Definition File for a MIDI controller is a XML file installed in MyDocuments/VirtualDJ/Devices/, with these properties:

the root element of the xml must be <device>, with these properties:
- name: unique string that identifies the controller, as will be used in the mapper
- author: (optional) name of the author of this xml file
- type: must be "MIDI"
- decks: can be "1" if the controller represents one deck, or "2" if it controls both decks at once.
- sysexid: (optional) answer to the Identity Request SysEx (see "identification" below)
- drivername: (optional) name of the driver
- drivernameout: (optional) name of the output driver if different
- midiin: (optional) number of the midi input interface on this computer
- midiout: (optional) number of the midi output interface on this computer
- sysexquery: (optional) SysEx to send to test for the device
- sysexanswer: (optional) SysEx to expect as an answer for this device


<?xml version="1.0" encoding="UTF-8"?>
<device name="MYCONTROLLER" author="Me" type="MIDI" decks="2" sysexid="F07E??06020001020304">

MIDI devices tool : Click here to download it.
(In this tool, "F0 7E 7F 06 01 F7" is the Identity Request SysEx query needed to get the Identity Request SysEx answer to use in "sysexid". See below)

Device Identification

In order to be automatically detected by VirtualDJ, the definition file must provide a way to identify if the device is present, and on which MIDI ports.
Several options are possible to achieve this, depending on how MIDI-compatible the device is.

If the device complies with MIDI specifications and answers to Identity Request SysEx ("System Exclusive"), then the best way is to provide the device ID answer.
You can do this by specifying sysexid= in the header with the expected SysEx answer.

The SysEx answer for an Identity Request should start with " F07E??0602 " (0xF0, 0x7E, <channel>, 0x06, 0x02), then the Manufacturer's ID (on 3 bytes, see some examples here), followed by the Device Family Code, the Device Family Member Code, the Software Revision Level, ...
(the ?? means you will detect the device whatever the MIDI channel is)

If the device doesn't answer to standard ID SysEx, but answers to some other proprietary SysEx, you can use it to detect the device.
Specify sysexquery= and sysexanswer= in the header, with the required SysEx codes.

Alternatively, if the device doesn't implement any SysEx, you can identify the device by the name of its driver.
Beware though that the driver name on Windows VISTA and Mac OSX can be changed by the user, or might differ on non-english versions of the OS, so this method is not 100% reliable.
To use the driver name as an identification, you can specify drivername= in the header.
If the output interface has a different name than the input, you can also add drivernameout=

If the driver doesn't have a unique name, as a last recourse you can identify the device by its number in the list of MIDI devices.
This would work only on the computer where you create the definition, and only as long as you don't add/remove new MIDI devices on your computer.
This form of identification can therefore be used only for development purpose, during the development and test stages of the controller.
To use this, specify midiin= and midiout= in the header.

Alternatively, if you don't provide any form of identification, then this definition file will be applied to all MIDI interfaces that are not matched by another definition.
If you need to create a definition file for your own use, you can use this to quickly get your device working.

If the encoder sends messages for increments and decrements of its position, you can defines it with a <encoder> element, with the following properties:
- cc: the MIDI cc
- inverted: (optional) set to "true" if the jog is inverted
- zero: set the cc value that represents zero. For a jog that sends 0x01 for forward movement and 0x7F for rewind, set this to "0" (default). For a jog that sends 0x41 for forward movement and 0x3F for rewind, set this to "0x40".
- max: (optional) specifies the value at which the encoder wraps

If the encoder sends messages with its absolute position, you can defines it with a <fullencoder> element, with the following properties:
- cc: the MIDI cc
- inverted: (optional) set to "true" if the jog is inverted
- full: set to the number of steps sent while performing a full rotation (by default 128)
- mask: (optional) set a bitmask to apply to the cc value

the XML file

If the device requires specific SysEx to be sent on exit, you can use <exit> elements, with the following properties:
- sendsysex: the list of hexadecimal values to send

Someone to whom this all makes sense wann point me in the right direction?
Does the device defintion need to refer to darouter, scs3d, both?
Is the device driver defined as Bomes?