HID support for windows have arrived in 4.7 - absolutely brilliant!!
I want to build my own HID joystick based on the teensy 3.1 board - specifically one with a LOT more sliders, as detailed [in the teensy forum](http://forum.pjrc.com/threads/23681-Man ... 053ce062d1).
The problem is that QLC+ only seem to recognise 6 axes and 32 buttons. I have compiled and loaded the 128 buttons, 17 sliders version of the joystick into my Teensy3.1 but QLC says 6 axes and 32 buttons.
My question is: does the HID interface plugin for QLC+ on windows, scan the device itself for the details on axis, sliders & buttons?
It may be that windows defaults to 6 axes & 32 buttons, but as far as I can see, there are some systems that read the device's capabilities from the device itself.
When I plug the joystick into linux and run QLC+ then it recognises 31 axes and 64 buttons. It also recognises a second joystick with 2 axes and 3 buttons.
The eventual dream is to build a 48 slider 128 button monster controller with 3 axis, non-return joysticks, 30 faders, 12 knobs and 2 x 64 buttons. But I need to get past the 6 axes first.
Windows HID - max axes
-
Massimo Callegari
Hey Chris, I think this is a Windows limitation.
These are the data structures Microsoft defined like 120 years ago, when complex devices like the one on your Teensy didn't exist:
http://msdn.microsoft.com/en-us/library ... s.85).aspx
http://msdn.microsoft.com/en-us/library ... s.85).aspx
Even the button mask refers to a maximum of 32 buttons.
As usual, you might try your luck with Linux, which is more flexible and stays at the pace of modern technologies but you'll probably need to tweak QLC+ a bit anyway.
I was wondering though if HID is the best interface for such device. In the end a joystick sends a position on 2 axes, so I guess 2 sliders can do the same if covered with the proper mechanics. So, for example, MIDI could do the job.
Another idea is to have multiple HID devices instead of a single one. If every Teensy joystick is exported as a single device, then you can extend it to the number you prefer and QLC+ will work with them as it is.
These are the data structures Microsoft defined like 120 years ago, when complex devices like the one on your Teensy didn't exist:
http://msdn.microsoft.com/en-us/library ... s.85).aspx
http://msdn.microsoft.com/en-us/library ... s.85).aspx
Even the button mask refers to a maximum of 32 buttons.
As usual, you might try your luck with Linux, which is more flexible and stays at the pace of modern technologies but you'll probably need to tweak QLC+ a bit anyway.
I was wondering though if HID is the best interface for such device. In the end a joystick sends a position on 2 axes, so I guess 2 sliders can do the same if covered with the proper mechanics. So, for example, MIDI could do the job.
Another idea is to have multiple HID devices instead of a single one. If every Teensy joystick is exported as a single device, then you can extend it to the number you prefer and QLC+ will work with them as it is.
-
Massimo Callegari
Edit: I didn't read the last part of your post.
Linux can read the right number of axes because it asks the kernel how many there are.
In Windows everything is hardcoded, even the audio devices names lenght which is truncated to 31 characters because the data structure was defined 150 years ago.
Linux can read the right number of axes because it asks the kernel how many there are.
In Windows everything is hardcoded, even the audio devices names lenght which is truncated to 31 characters because the data structure was defined 150 years ago.
-
Massimo Callegari
http://www.nsaneforums.com/topic/40180- ... urce-code/
This is a joke but it's not so far from the truth
Windows hasn't really progressed that much through the years.
Microsoft just changed the UI and did their worst....see the abomination they've done on Windows 8
This is a joke but it's not so far from the truth
Windows hasn't really progressed that much through the years.
Microsoft just changed the UI and did their worst....see the abomination they've done on Windows 8
-
Chris Laurie
Thanks Massimo - as I understand it, there are definitely games that bypasses the Windows limitation. I will study that and post here if I find anything. Maybe it would be possible to implement in Qt
I want to do HID because of the resolution issues with MIDI, which is limited to a resolution of 125. This is not the best if I want to control the exact position of a moving head.
In essence HID outputs a 512bit packet and how that packet is interpreted, depends on how the headers are defined. It is Windows that decided that 6 axes is the max (like 640kb ought to be enough for anybody, I suppose). The HID spec allows for any number of controlling devices as long as the headers are correct and you are sticking to 512bits.
The beauty of the Teensy is that, changing it to a midi device, is a software change and one controls the data flow with an Arduino sketch. So I may try doing it as a midi anyway. The hardware side (mux demux and reading of the slider values and button states) stay the same.
I want to do HID because of the resolution issues with MIDI, which is limited to a resolution of 125. This is not the best if I want to control the exact position of a moving head.
In essence HID outputs a 512bit packet and how that packet is interpreted, depends on how the headers are defined. It is Windows that decided that 6 axes is the max (like 640kb ought to be enough for anybody, I suppose). The HID spec allows for any number of controlling devices as long as the headers are correct and you are sticking to 512bits.
The beauty of the Teensy is that, changing it to a midi device, is a software change and one controls the data flow with an Arduino sketch. So I may try doing it as a midi anyway. The hardware side (mux demux and reading of the slider values and button states) stay the same.
-
Chris Laurie
BTW Massimo, which library are you using in QLC+. I have come across [HIDAPI](http://www.signal11.us/oss/hidapi/) that seems to do a low level read. I'm so out of my depth here...
-
Massimo Callegari
https://github.com/mcallegari/qlcplus/t ... /hid/win32
HIDAPI it is
However, I contacted the author (Alan Ott) and he told me hidapi is not for joysticks. In fact I had to tweak it, especially on Linux.
He wrote the code only for HID raw devices.
As for games bypassing the Windows limitation, I believe that.
However, the policy I have in mind for QLC+ plugins is that they have to be the pure implementation of standards.
If we start writing custom code for each device, they're gonna become a mess pretty soon.
In this forum there's been a few ideas for QLC+ based consoles. For example Sven Meier wrote a bit about the one he's building.
Maybe if you guys talk to each other, there is the possibility to converge to a brilliant and unique solution that can be sponsored in the QLC+ website.
I would support that and eventually write a bit of code for it.
What I can't do (and absolute no offense to you) is write custom code for each idea happening around QLC+
HIDAPI it is
However, I contacted the author (Alan Ott) and he told me hidapi is not for joysticks. In fact I had to tweak it, especially on Linux.
He wrote the code only for HID raw devices.
As for games bypassing the Windows limitation, I believe that.
However, the policy I have in mind for QLC+ plugins is that they have to be the pure implementation of standards.
If we start writing custom code for each device, they're gonna become a mess pretty soon.
In this forum there's been a few ideas for QLC+ based consoles. For example Sven Meier wrote a bit about the one he's building.
Maybe if you guys talk to each other, there is the possibility to converge to a brilliant and unique solution that can be sponsored in the QLC+ website.
I would support that and eventually write a bit of code for it.
What I can't do (and absolute no offense to you) is write custom code for each idea happening around QLC+
-
Chris Laurie
I agree absolutely with the principle of pure implementation of standards, I just hope there is better implementation of the HID standard, that is not OS specific. I certainly don't think it is a good idea to write anything only for a specific device.
The Teensy of course can do HID raw....
The Teensy of course can do HID raw....
-
Massimo Callegari
Chris the fact is that "raw" means everything and nothing.
It just means that you will receive a bunch of bytes that you will need to interpret.
That's why in Linux, for example, there are a number of abstractions of the HID devices. To give developers a friendly way to read those bytes.
In other words, the Teensy will send a train of data, and then QLC+ will have to know how to read them. Means custom code
It just means that you will receive a bunch of bytes that you will need to interpret.
That's why in Linux, for example, there are a number of abstractions of the HID devices. To give developers a friendly way to read those bytes.
In other words, the Teensy will send a train of data, and then QLC+ will have to know how to read them. Means custom code
-
Chris Laurie
I didn't really suggest QLC+ does raw HID...
The Teensy behaves like an actual joystick (if programmed that way). The big controller always defines its first 6 faders as axes Usage (X), Usage (Y), Usage (Z), Usage (Rx), Usage (Ry), Usage (Rz) Thereby conforming to the windows way of doing things.
It does however also allow for further definitions of Usage (Slider). So the bits returned by Teensy (when acting as a joystick) is interpreted by the HID protocol according to the specification issued by the device. So he envisaged big controller would still have X, Y, Z and Rx, Ry and Rz axis.
This is established when the device is plugged in. I was able, so far, to change the name and product ID of the Teensy device and get QLC to read that.
There is no change in the Teensy that is plugged into the Windows box and the Linux box. The Linux box just enumerates capability correctly, while Windows imposes an arbitrary structure.
I'm hoping one can implement something that reads and assigns the windows structure but then looks beyond that using the HID spec to get the sent values.
The Teensy behaves like an actual joystick (if programmed that way). The big controller always defines its first 6 faders as axes Usage (X), Usage (Y), Usage (Z), Usage (Rx), Usage (Ry), Usage (Rz) Thereby conforming to the windows way of doing things.
It does however also allow for further definitions of Usage (Slider). So the bits returned by Teensy (when acting as a joystick) is interpreted by the HID protocol according to the specification issued by the device. So he envisaged big controller would still have X, Y, Z and Rx, Ry and Rz axis.
This is established when the device is plugged in. I was able, so far, to change the name and product ID of the Teensy device and get QLC to read that.
There is no change in the Teensy that is plugged into the Windows box and the Linux box. The Linux box just enumerates capability correctly, while Windows imposes an arbitrary structure.
I'm hoping one can implement something that reads and assigns the windows structure but then looks beyond that using the HID spec to get the sent values.