iCon iStage support

[Bendrien]

I love the layout of the iStage but there is almost no support for using it in an unintended way. Therefore i would like to see support for this controller in the ctlra library. Most importantly establishing a communication to the button leds and the 7 segment display.

How should i proceed?

[harryhaaren]

Hey, pasting the usbview output for the device should show us how the USB device looks, and then we'll have to try get some of the information on button pushes etc from it. Do you know/have any data on how to turn on the LEDs? Or do you have an application that can light up the lights, so we can reverse-engineer the data-stream?

[Bendrien]

Here is the usbview output:

CON iStage V1.03
Manufacturer: iCON
Serial Number: 09101
Speed: 12Mb/s (full)
USB Version:  1.10
Device Class: 00(>ifc )
Device Subclass: 00
Device Protocol: 00
Maximum Default Endpoint Size: 16
Number of Configurations: 1
Vendor Id: 1d03
Product Id: 002f
Revision Number:  1.00

Config Number: 1
	Number of Interfaces: 2
	Attributes: 80
	MaxPower Needed: 100mA

	Interface Number: 0
		Name: snd-usb-audio
		Alternate Number: 0
		Class: 01(audio) 
		Sub Class: 01
		Protocol: 00
		Number of Endpoints: 0

	Interface Number: 1
		Name: snd-usb-audio
		Alternate Number: 0
		Class: 01(audio) 
		Sub Class: 03
		Protocol: 00
		Number of Endpoints: 2

			Endpoint Address: 82
			Direction: in
			Attribute: 2
			Type: Bulk
			Max Packet Size: 4
			Interval: 0ms

			Endpoint Address: 02
			Direction: out
			Attribute: 2
			Type: Bulk
			Max Packet Size: 4
			Interval: 0ms

[harryhaaren]

Ah ok, so this is a USB Bulk device (most new devices now use USB HID instead, because it scales a bit better). I expect that pressing a button will make data appear on Config 1 : Interface 1 : Endpoint 82 which is the "in" direction towards the CPU. The hard question will be what data-format is required on the "Out" direction (CPU -> device) to make the lights appear as required.

Looking at the "max packet size" of 4 is tiny (usb transactions tend to be > 64 bytes at least), so this suggests that the protocol is some quiet small data-format, and that each control / button would send its own message... (new devices use a single USB HID transfer for multiple buttons/faders)

Given MIDI is 3 bytes, perhaps there's just a single byte of "padding" or something at the beginning, followed by a standard MIDI message - total guess, but that could be somewhere to start looking.

Next steps for input is to print out the data as it is recieved, and try to identify a pattern. That allows us to identify if it is a stream of individual messages per controller as I'm guessing above, and if so, it will give some suggestions as to how the output data might be structured (assuming its similar to normal MIDI controllers ways of turning on/off LEDs).

[Bendrien]

Do you know/have any data on how to turn on the LEDs? Or do you have an application that can light up the lights, so we can reverse-engineer the data-stream?

You have to turn the device into "Traktor Mode" with the "iMap" software and select the dj page. Then while holding midinote 0 to 48 one can turn all main pad leds into red going row by row. This excludes the outer buttons, mode and setting buttons.