ok, created a new category for developer discussions... Ive also switch the home page such that it now shows categories as the first (you can click on latest to see previous view) , its quite nice, as it still shows latest in each category.
I don't want to hide it from the home page, as for developers, they will just miss any post in it,
but an option ( which Ive not done) is to have a 'closed group' for developers, this way the category/topics would only be shown to invited members only... but I think dividing the community is probably not a good idea... as we don't know if new members will be interested etc.
so lets see how this goes for now.
back on topic....
USB2 HS, ok will check the push 2... this could well be the issue. (hmm, need to check my other controllers I think the Eigenharp Alpha is USB2 HS) , not a big issue, the PI2 as a master is looking increasingly attractive.
Alternative settings, yeah, its odd, even the Virus is not really using it, but it completely screws up the handling in the STM code which assumes one descriptor/setting per interface.
(my 'fix' just stops the corruption caused, rather than support alternative settings, as I think your right its not used often)
composites device, yeah these are really common... frankly STMs implementation is very naive.
yeah I saw your 'fix' for the mini mk2, but really it just is a band-aid... what if you also wanted to support the HID interface as well?
as I said i think there are two fixes...
- replace the STM implementation, for something that allows per interface class implementations.
- create a 'proxy' class for each interface class, which then can allow for implementations inserted.
neither is trivial, but the later probably is 'safer', and frankly the USB host code we have already needs re-visting and cleaning up anyway (I did do quite a bit on the usb midi host, but there still is a bit of dead code in there)
essentially this would mean, the STM code, would continue to match the first interface to the first interface class to hit the proxy. and the proxy then would then hold a list of known implementations to find the match.
this match could included checking not only classes, but also things like VID/PID.
(which is what Im doing on the Virus implementation, which needs a message sent to put the Virus into USB midi mode)
my current thought is to do something which, moves us in this direction, even if its not a full implementation.
the other thing Id like to do is to add some firmware 'preferences' to the preferences dialog, such that you can add 'flags' to optionally compile in bits of firmware.
(the more custom devices we have, the less likely we are to want them all in the firmware)