45 replies to this topic

[MWeston]

- create a thread that runs forever:

- wake it up no more than 60 times per second to poll iCP for data.  The nubs are only updated 40 times per second.

- The digital controls are updated any time you need them.

- the more you poll it, the more power the iCP will use because you won't let it go back to sleep as often. <img src='http://boards.openpandora.org/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />



- here is a simple poll for digital controls:

  - send <0xA5> to poll for game button data

  #define CMD_GET_DIGITALS			0xA5

  - wait for two bytes to be received: <byte A> and <byte B> in that order

  - byte A has these bits active ('1' = pressed, '0' = released):

  #define GB_DPAD_LEFT				2	//A

  #define GB_DPAD_RIGHT				1	//A

  #define GB_DPAD_UP				0	//A

  #define GB_DPAD_DOWN				3	//A

  #define GB_SHLDR_LEFT				4	//A

  - byte B has these bits active ('1' = pressed, '0' = released):

  #define GB_SHLDR_RIGHT			6	//B

  #define GB_BTN_A				3	//B

  #define GB_BTN_B				5	//B

  #define GB_BTN_X				4	//B

  #define GB_BTN_Y				2	//B

  #define GB_BTN_START				1	//B

  #define GB_BTN_SELECT				0	//B



  - All other bits in these bytes will be '0'



- here is a simple poll for analog controls:

  - send <0x46><0x01> to iCP.  This enables analog scanning.  By default it is off to save power.

  #define CMD_FORCE_NUB_SCAN			0x46

  #define SET_ON				0x01

  - the iCP will respond with <0x80> when done.  The nubs are now active.

  #define RESP_OKAY				0x80

  - send <0x87> to poll for analog positions

  #define CMD_GET_ANALOGS			0x87

  - wait for four bytes to be received: <Nub1 X> <Nub1 Y> <Nub2 X> <Nub2 Y>

  - the bytes are signed.  The values will range from -32 to +32.

    - +32 is full up or full right

    - -32 is full down or full left

    - 0,0 is center of course



- here is a routine that should be added (probably to start of infinite thread before the big while(1) loop):

  - To see if an iCP is connected to the iDevice, send <0xB3>

  #define CMD_PING_ICP				0xB3

  - The reply will be <0x44><0x88><0xCC> if connected and had enough time to initialize.  No reply means the iCP is not connected or

    hasn't finished booting and initializing yet.  We have to figure out how long that is but for now, no wait is okay as

    long as the app isn't started immediately after waking the phone up.

  #define ICP_ALIVE1				0x44

  #define ICP_ALIVE2				0x88

  #define ICP_ALIVE3				0xCC

  - If no response is given before the end of a timeout period, no communication to the iCP should happen at all since it is presumed 

    missing.  You could also try multiple attempts in case of a communication error.



- before you close your app, you should turn off the unused features

  - Example: turn off the analog nub polling

  - send <0x46><0x00> to iCP.

  #define CMD_FORCE_NUB_SCAN			0x46

  #define SET_OFF				0x00

  - the iCP will respond with <0x80> when done.  The nubs are now off.

  #define RESP_OKAY				0x80



- Controlling the charger is done in hardware/iCP firmware by default, but there are manual settings to force it off or let it turn back

  on.  You can also monitor the battery voltage and make a little battery picture in your application or something like that.



- You can check the iCP's version number by sending <0x39>

  #define CMD_GET_ID				0x39

  - the response is a long string of characters ending with a carriage return and line feed.



- You can check the battery's voltage by sending <0xAA>

  #define CMD_GET_BATT_VOLTS			0xAA

  - the response will be three readable characters in this example format: 405  <-- This means 4.05 volts.



- You can check the battery for a general level by sending <0x55>

  #define CMD_GET_BATT_LEVEL			0x55

  - The response will be a single byte with the following significance.

  #define BATT_FULL				6

  #define BATT_ALMOST_FULL			5

  #define BATT_3_4_FULL				4

  #define BATT_HALF_FULL			3

  #define BATT_1_4_FULL				2

  #define BATT_ALMOST_DEAD			1

  #define BATT_DEAD				0

  - The definition for these levels are estimated right now and not expected to be particularly accurate.



- You can check the status of the charger to the iDevice by sending <0xDE>

  #define CMD_GET_CHGR_STATUS			0xDE

  - The response will be one byte signifying either on or off as follows:

  #define SET_ON				0x01

  #define SET_OFF				0x00



- You can force the charger to the iDevice to be on or off by sending <0x2A>

  #define CMD_FORCE_CHARGER			0x2A

  With either one of these parameter to turn on or off:

      #define SET_ON				0x01

      #define SET_OFF				0x00

  - The response will be one byte to signify if the action could be completed

  #define RESP_OKAY				0x80

  #define RESP_NOT_OKAY				0x81

  - You can always force the charger off but you cannot force it on if the iCP detects a low battery or an external charger is already

    plugged in



- If you don't need to check battery levels, you can shut that feature off to save power

  - Send the command <0x51>

    #define CMD_FORCE_BATT_SCAN		        0x51

    With either one of these parameter to turn on or off:

      #define SET_ON				0x01

      #define SET_OFF				0x00

  - The response will be a single byte to signify if the action could be done:

      #define RESP_OKAY				0x80

      #define RESP_NOT_OKAY			0x81

  - The action will be denied if battery charging is on because the device must constantly monitor the battery.  If you

    successfully turn it off, it will be re-enabled automatically if charging is started again.



- The activity of the power LED can be changed manually by sending the command <6D>

  #define CMD_FORCE_LED_CTRL			0x6D

  - Then send the parameter to tell the iCP if you want control of the LED or not:

      #define SET_ON				0x01

      #define SET_OFF				0x00

  - ON means you want to override the iCP's internal control.  The LED will be forced off at this point.

  - OFF means you want to give back control to the iCP

  - The response will always be positive:

  #define RESP_OKAY				0x80

  - Once control is established, turn the LED ON with the command <0xFF>

  #define CMD_SET_LED				0xFF

  - Then send the parameter for on or off:

  #define SET_ON				0x01

  #define SET_OFF				0x00

  - The response will signify if the action could be completed:

  #define RESP_OKAY				0x80

  #define RESP_NOT_OKAY				0x81

  - If you have not taken control of the LED, your request will be denied with a not okay reply.



- The activity of the power LED can be changed to alter its behavior when the iCP hardware has control of it.

  Currently, the iCP uses the LED to indicate power status and internal battery low conditions only.

  - Send the command <0xE4>

  #define CMD_SET_LED_MODE			0xE4

  - Send one of the parameters to change the mode:

  #define LED_PULSE_DOUBLE			0

  #define LED_PULSE_FAST			1

  #define LED_PULSE_INVERSE			2

  #define LED_NO_PULSE				3

  #define LED_LOW_BATT_IND			4

  - Pulse double: LED is normally off but blinks once every 5 seconds.  It will do a double blink if the battery is low.

  - Pulse fast: LED is normally off but blinks once every 5 seconds.  If the battery is low, it will change blink rate to

    once every 1 second.

  - Pulse inverse: LED is normally on but blinks off once every 5 seconds when battery is low 

  - No pulse: LED is always on unless battery is low.  Then it stays off until battery is recharged (to a certain threshold).

  - Low batt ind: LED is always off unless battery is low.  Then it stays on until battery is recharged (to a certain threshold).



- There are many bytes of non-volatile memory in the iCP that can be used to store anything.

  - To read a byte of memory send the command <0x9A>

  #define CMD_READ_EEPROM			0x9A

  - Then send the two byte address of the single byte to read.  The range is 0 - 511:

    <low byte><highbyte> 

  - The response will be the data as a single byte reply.  If the address is out of range, the response will be a <0x00>.

  - To write a byte, send the command <0x7A>

  #define CMD_WRITE_EEPROM			0x7A

  - Then send the two byte address of the single byte to write.  The range is currently 0 - 503.  Currently the upper 8

    bytes are reserved for the iCP's internal use and for serial numbers.

    <low byte><highbyte>

  - Next send a security byte to verify this operation is to happen:

  #define SECURE_EE_BYTE			0x19

  - Then send the single byte of data to write

  - The response will signify if the action could be completed:

  #define RESP_OKAY				0x80

  #define RESP_NOT_OKAY				0x81

  - Attempting to write out of range will be denied.



- The baud rate of communication can be changed at any time.  The default on power up will always be 9600bps though.

  This way the iCP will always come up at a known speed regardless of what app tried to change it.

  - To set the baud rate, send the command <0xC2>

  #define CMD_CHANGE_BAUD_RATE		        0xC2

  - Then send the single byte parameter for the new rate:

  #define BAUD_RATE_9600			1			

  #define BAUD_RATE_19200			2

  #define BAUD_RATE_38400			3

  #define BAUD_RATE_57600			4

  #define BAUD_RATE_115200			5

  - The iCP will immediate reply at the current baud rate with a reply signifying if the action can be done:

  #define RESP_OKAY				0x80

  #define RESP_NOT_OKAY				0x81

  - If the parameter sent is not supported, the action will be denied.  Otherwise it will proceed.

  - If the action is accepted, the iCP will wait 2 milliseconds, change the rate and continue on waiting for new

    commands at the new baud rate until it is changed again or until power is lost.



- Firmware upgrading:

  - Protocol not publicly available

[JayFoxRox]

/*
- create a thread that runs forever:
- wake it up no more than 60 times per second to poll iCP for data.  The nubs are only updated 40 times per second.
- The digital controls are updated any time you need them.
- the more you poll it, the more power the iCP will use because you won't let it go back to sleep as often. <img src='http://boards.openpandora.org/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />

- here is a simple poll for digital controls:
  - send <0xA5> to poll for game button data
*/
  #define ICP_CMD_GET_DIGITALS			0xA5
/*
  - wait for two bytes to be received: <byte A> and <byte B> in that order
  - byte A has these bits active ('1' = pressed, '0' = released):
*/
  #define ICP_GB_DPAD_LEFT				2	//A
  #define ICP_GB_DPAD_RIGHT				1	//A
  #define ICP_GB_DPAD_UP				0	//A
  #define ICP_GB_DPAD_DOWN				3	//A
  #define ICP_GB_SHLDR_LEFT				4	//A
/*
  - byte B has these bits active ('1' = pressed, '0' = released):
*/
  #define ICP_GB_SHLDR_RIGHT			6	//B
  #define ICP_GB_BTN_A				3	//B
  #define ICP_GB_BTN_B				5	//B
  #define ICP_GB_BTN_X				4	//B
  #define ICP_GB_BTN_Y				2	//B
  #define ICP_GB_BTN_START				1	//B
  #define ICP_GB_BTN_SELECT				0	//B
/*
  - All other bits in these bytes will be '0'

- here is a simple poll for analog controls:
  - send <0x46><0x01> to iCP.  This enables analog scanning.  By default it is off to save power.
*/
  #define ICP_CMD_FORCE_NUB_SCAN			0x46
  #define ICP_SET_ON				0x01
/*
  - the iCP will respond with <0x80> when done.  The nubs are now active.
*/
  #define ICP_RESP_OKAY				0x80
/*
  - send <0x87> to poll for analog positions
*/
  #define ICP_CMD_GET_ANALOGS			0x87
/*
  - wait for four bytes to be received: <Nub1 X> <Nub1 Y> <Nub2 X> <Nub2 Y>
  - the bytes are signed.  The values will range from -32 to +32.
    - +32 is full up or full right
    - -32 is full down or full left
    - 0,0 is center of course

- here is a routine that should be added (probably to start of infinite thread before the big while(1) loop):
  - To see if an iCP is connected to the iDevice, send <0xB3>
*/
  #define ICP_CMD_PING_ICP				0xB3
/*
  - The reply will be <0x44><0x88><0xCC> if connected and had enough time to initialize.  No reply means the iCP is not connected or
    hasn't finished booting and initializing yet.  We have to figure out how long that is but for now, no wait is okay as
    long as the app isn't started immediately after waking the phone up.
*/
  #define ICP_ICP_ALIVE1				0x44
  #define ICP_ICP_ALIVE2				0x88
  #define ICP_ICP_ALIVE3				0xCC
/*
  - If no response is given before the end of a timeout period, no communication to the iCP should happen at all since it is presumed 
    missing.  You could also try multiple attempts in case of a communication error.

- before you close your app, you should turn off the unused features
  - Example: turn off the analog nub polling
  - send <0x46><0x00> to iCP.
*/
  #define ICP_CMD_FORCE_NUB_SCAN			0x46
  #define ICP_SET_OFF				0x00
/*
  - the iCP will respond with <0x80> when done.  The nubs are now off.
*/
  #define ICP_RESP_OKAY				0x80
/*
- Controlling the charger is done in hardware/iCP firmware by default, but there are manual settings to force it off or let it turn back
  on.  You can also monitor the battery voltage and make a little battery picture in your application or something like that.

- You can check the iCP's version number by sending <0x39>
*/
  #define ICP_CMD_GET_ID				0x39
/*
  - the response is a long string of characters ending with a carriage return and line feed.

- You can check the battery's voltage by sending <0xAA>
*/
  #define ICP_CMD_GET_BATT_VOLTS			0xAA
/*
  - the response will be three readable characters in this example format: 405  <-- This means 4.05 volts.

- You can check the battery for a general level by sending <0x55>
*/
  #define ICP_CMD_GET_BATT_LEVEL			0x55
/*
  - The response will be a single byte with the following significance.
*/
  #define ICP_BATT_FULL				6
  #define ICP_BATT_ALMOST_FULL			5
  #define ICP_BATT_3_4_FULL				4
  #define ICP_BATT_HALF_FULL			3
  #define ICP_BATT_1_4_FULL				2
  #define ICP_BATT_ALMOST_DEAD			1
  #define ICP_BATT_DEAD				0
/*
  - The definition for these levels are estimated right now and not expected to be particularly accurate.

- You can check the status of the charger to the iDevice by sending <0xDE>
*/
  #define ICP_CMD_GET_CHGR_STATUS			0xDE
/*
  - The response will be one byte signifying either on or off as follows:
*/
  #define ICP_SET_ON				0x01
  #define ICP_SET_OFF				0x00
/*
- You can force the charger to the iDevice to be on or off by sending <0x2A>
*/
  #define ICP_CMD_FORCE_CHARGER			0x2A
/*
  With either one of these parameter to turn on or off:
*/
      #define ICP_SET_ON				0x01
      #define ICP_SET_OFF				0x00
/*
  - The response will be one byte to signify if the action could be completed
*/
  #define ICP_RESP_OKAY				0x80
  #define ICP_RESP_NOT_OKAY				0x81
/*
  - You can always force the charger off but you cannot force it on if the iCP detects a low battery or an external charger is already
    plugged in

- If you don't need to check battery levels, you can shut that feature off to save power
  - Send the command <0x51>
*/
    #define ICP_CMD_FORCE_BATT_SCAN		        0x51
/*
    With either one of these parameter to turn on or off:
*/
      #define ICP_SET_ON				0x01
      #define ICP_SET_OFF				0x00
/*
  - The response will be a single byte to signify if the action could be done:
*/
      #define ICP_RESP_OKAY				0x80
      #define ICP_RESP_NOT_OKAY			0x81
/*
  - The action will be denied if battery charging is on because the device must constantly monitor the battery.  If you
    successfully turn it off, it will be re-enabled automatically if charging is started again.

- The activity of the power LED can be changed manually by sending the command <6D>
*/
  #define ICP_CMD_FORCE_LED_CTRL			0x6D
/*
  - Then send the parameter to tell the iCP if you want control of the LED or not:
*/
      #define ICP_SET_ON				0x01
      #define ICP_SET_OFF				0x00
/*
  - ON means you want to override the iCP's internal control.  The LED will be forced off at this point.
  - OFF means you want to give back control to the iCP
  - The response will always be positive:
*/
  #define ICP_RESP_OKAY				0x80
/*
  - Once control is established, turn the LED ON with the command <0xFF>
*/
  #define ICP_CMD_SET_LED				0xFF
/*
  - Then send the parameter for on or off:
*/
  #define ICP_SET_ON				0x01
  #define ICP_SET_OFF				0x00
/*
  - The response will signify if the action could be completed:
*/
  #define ICP_RESP_OKAY				0x80
  #define ICP_RESP_NOT_OKAY				0x81
/*
  - If you have not taken control of the LED, your request will be denied with a not okay reply.

- The activity of the power LED can be changed to alter its behavior when the iCP hardware has control of it.
  Currently, the iCP uses the LED to indicate power status and internal battery low conditions only.
  - Send the command <0xE4>
*/
  #define ICP_CMD_SET_LED_MODE			0xE4
/*
  - Send one of the parameters to change the mode:
*/
  #define ICP_LED_PULSE_DOUBLE			0
  #define ICP_LED_PULSE_FAST			1
  #define ICP_LED_PULSE_INVERSE			2
  #define ICP_LED_NO_PULSE				3
  #define ICP_LED_LOW_BATT_IND			4
/*
  - Pulse double: LED is normally off but blinks once every 5 seconds.  It will do a double blink if the battery is low.
  - Pulse fast: LED is normally off but blinks once every 5 seconds.  If the battery is low, it will change blink rate to
    once every 1 second.
  - Pulse inverse: LED is normally on but blinks off once every 5 seconds when battery is low 
  - No pulse: LED is always on unless battery is low.  Then it stays off until battery is recharged (to a certain threshold).
  - Low batt ind: LED is always off unless battery is low.  Then it stays on until battery is recharged (to a certain threshold).

- There are many bytes of non-volatile memory in the iCP that can be used to store anything.
  - To read a byte of memory send the command <0x9A>
*/
  #define ICP_CMD_READ_EEPROM			0x9A
/*
  - Then send the two byte address of the single byte to read.  The range is 0 - 511:
    <low byte><highbyte> 
  - The response will be the data as a single byte reply.  If the address is out of range, the response will be a <0x00>.
  - To write a byte, send the command <0x7A>
*/
  #define ICP_CMD_WRITE_EEPROM			0x7A
/*
  - Then send the two byte address of the single byte to write.  The range is currently 0 - 503.  Currently the upper 8
    bytes are reserved for the iCP's internal use and for serial numbers.
    <low byte><highbyte>
  - Next send a security byte to verify this operation is to happen:
*/
  #define ICP_SECURE_EE_BYTE			0x19
/*
  - Then send the single byte of data to write
  - The response will signify if the action could be completed:
*/
  #define ICP_RESP_OKAY				0x80
  #define ICP_RESP_NOT_OKAY				0x81
/*
  - Attempting to write out of range will be denied.

- The baud rate of communication can be changed at any time.  The default on power up will always be 9600bps though.
  This way the iCP will always come up at a known speed regardless of what app tried to change it.
  - To set the baud rate, send the command <0xC2>
*/
  #define ICP_CMD_CHANGE_BAUD_RATE		        0xC2
/*
  - Then send the single byte parameter for the new rate:
*/
  #define ICP_BAUD_RATE_9600			1			
  #define ICP_BAUD_RATE_19200			2
  #define ICP_BAUD_RATE_38400			3
  #define ICP_BAUD_RATE_57600			4
  #define ICP_BAUD_RATE_115200			5
/*
  - The iCP will immediate reply at the current baud rate with a reply signifying if the action can be done:
*/
  #define ICP_RESP_OKAY				0x80
  #define ICP_RESP_NOT_OKAY				0x81
/*
  - If the parameter sent is not supported, the action will be denied.  Otherwise it will proceed.
  - If the action is accepted, the iCP will wait 2 milliseconds, change the rate and continue on waiting for new
    commands at the new baud rate until it is changed again or until power is lost.

- Firmware upgrading:
  - Protocol not publicly available
*/

Tried to fix that for you, but the forum highlighting sucks - someone make those comments green

[evill33t]

Hi and thanks for the guide, is there a possibility to test this in the simulator?

[Stu]

Looks really straight forward - serial. I wonder if iCP could be used on non-jailbroken devices if some like Redpark actually releases this dock to serial adapter with an SDK. Apple no longer requires accessories be paired with a single app.

Cheers,

Stu

[David994A]

Is there a guide or at least some code examples for programming for Bluetooth? I'm particularly interested in programming for a non-jailbroken device. I understand that the analog nubs are not supposed to work for non-jailbroken devices but that is ok.

[Craigix]

Yes there is a new guide, Michael will post it.

[EvilDragon]

Here it is

It doesn't have a nice design yet, but everything you need should be in there

[torpor]

I really wish we could just use CoreMIDI with this thing. What about a slight tweak the firmware, Craig?

[Craigix]

I really wish we could just use CoreMIDI with this thing. What about a slight tweak the firmware, Craig?

Can you explain the advantages of it?

[David994A]

Thanks for posting the doc, I'll check it over

[David994A]

I just looked it over. Nice doc.

Do you have any programming examples for using HID keyboard mode or information about the bluetooth pairing with an iPhone. I can't find any information on the apple developer site on how to get bt keyboard events into your app. I'm particularly interested in using this for a non-jailbroken application.

[SOLGarion]

I really wish we could just use CoreMIDI with this thing. What about a slight tweak the firmware, Craig?

Can you explain the advantages of it?

I haven't programmer midi but used it a shit load as a musician Coremidi framework provides the API's to communicate midi data, usually from musical instruments. The iPhone does accept midi since I have seen many approved peripherals and apps for the iPhone that use midi data. So if the program saw the icp as a midi device then you could use it that way for non jailbroken apps. Midi gives you 128 levels, which should e more than enough for one per button and a bunch for smooth analog nubs. I would hope the iPhone doesn't err slow down midi data like it does character data since lag would kill a lot of musical applications that midi allows.

I THINK that would be the purpose of using midi. In another thread a dude showed a YouTube clip of a ps2 controller hacked to use midi data, so there is your proof of concept.

[torpor]

SOLGarion has got it mostly right Craig, if you had a standard USB->MIDI rig for the iCP, you wouldn't need a jailbreak at all. There is, however, a current gotcha.

Apple have given us MIDI to use on iOS in the latest release - this is being done to open up the iDevices to being used, more and more, in studios. I have my iPad jammed full of great synthesizers and control-apps that I can use to control all my external, older gear (many people still swear by MIDI, me included) .. and so on. In fact my iPad has replaced my laptop for controlling my whole synthesizer rig - its that damn good. I'm not using the iPad as a DAW, but as a master control panel/sequencing system for my 19" racks and multiple external synths. Also, I can't get enough of the iMS20 app ..

This is possible because my iPad has the USB Connection kit pretty much glued to its i/o port these days, and into that I can use this cable:

http://www.amazon.com/Input-Output-Cable-Converter-Notebook/dp/B001HPL8B2/ref=sr_1_3?ie=UTF8&qid=1297546277&sr=8-3

Thats a USB-MIDI cable. With it, I can communicate to my iPad from my keyboard controller, external synthesizers/drum machines, and so on ..

And on iOS at least, USB-MIDI is now a class-level driver -i.e. its so standardized (in OSX/Linux/Win) that you don't need to write a device driver for it - if the cable reports the right configuration, then the iOS 'class compliant' builtin driver will be used to do standard MIDI I/O over the cable, and app developers can just use plain old CoreMIDI to get controller info ..

For iOS this means, you can plug your iDevice into tons of other gear.

Now, this is true at least for the iPad - on the iPhone, it is alas a little bit different. We have MIDI-over-WLAN on the iPhone (iPad too), but Apple haven't enabled support for the USB Connector on iPhone(4,3G,etc.) .. yet. There is some controversy over whether they're going to let USB-MIDI be so simple on iPhone4, or if its going to be a 'feature' for iPhone5 that you can plug lots of USB devices in. So .. for now .. MIDI-over-Wlan would be the way to go, to support iPhones.

There are two approaches to using MIDI in the iCP:

a) put a simple USB-UART chip in the iCP (USB-MAX232R?), and configure it for a standard 1-port MIDI output device. When the user plugs in the MIDI-ized ICP, any app which uses CoreMIDI can receive controller events.
put a slightly less-simple (but nevertheless feasible) WLAN+MCU in the iCP, and implement MIDI-over-WLan.

Option a) would be cheaper, but not (immediately) compatible with iPhone4/3G devices (iPad, yes, iPhone5 .. probably). This might change - Apple could put USB-connector kit software in the next iOS update that will enable it in iPhone4, at least.

Option would be a little more expensive, on the order of (perhaps) $5 more per chip, and have different power requirements - but you'd get 100% compatability with MIDI-over-WLan on CoreMIDI, and so on ..

BTW, its really, really easy to make a class-compliant USB-MIDI cable. Its just a pair of UARTs, essentially, and you can buy a USB-UART solution for very low cost. I *think* it could be nearly as easy to put a WLAN+MCU in the iCP, if you shop properly.

Midi gives you 128 levels, which should e more than enough for one per button and a bunch for smooth analog nubs.

Well .. if you use MIDI CC (Continuous controller) messages, you get 127 data values .. but if you use instead MIDI NRPN's, you can get much higher resolution .. not that its really needed for the game-playing crowd, but then again why not ..


EDIT:

Can you explain the advantages of it?

The advantage: no jailbreak required, and if its done properly, the iCP can be used as a USB-MIDI controller (i.e. no driver stress on other OS/environments) on all other platforms, too. Android, for example, also has a USBMIDI class compliant driver (its superlative on Linux, frankly), OSX has had it for years, and so on..

Basically, to an application, the iCP would look like one of these:

http://www.faderfox.de/mark/index.php?option=com_content&view=article&id=149&Itemid=174

.. or more specifically, one of these:

http://www.faderfox.de/mark/index.php?option=com_content&view=article&id=153&Itemid=175




(Also a terrific device to plug into my iPad, although I've got the older, MIDI-only one ..)

[SOLGarion]

I still have my old midi adapter for my yamaha psr620. Sad thing is the adapter "adapts" a joystick port into a midi one. Now I just need an adapter for the joystick end... Adapter on an adapter. Hehe. Midi making a huge come back in the last 5-10 years. In mid 90s when I used it more it was being phased out, or at least it was tried. Everyone go t so hopped up on audio formats like mp3s and such that SOME people stopped supporting it as much. So much you can do with it besides make retro 8/16 bit game music.

[Craigix]

Sounds like a nice hack, I'll see if we can add it to the firmware if it isn't too complex.

Remember though, apple might just reject the app.

[torpor]

Sounds like a nice hack, I'll see if we can add it to the firmware if it isn't too complex.

If you can set up a Bluetooth-PAN between the iCP and iDevice, I think you can then do MIDI-over-network .. and developers just use CoreMIDI for input.

Remember though, apple might just reject the app.

For implementing CoreMIDI-based control over their game? Really? I think that would be a bit of a stretch .. there are MIDI joysticks and other control surfaces, out there ..

[Craigix]

But we're at the mercy of the crazy, secretive, thirsty, paranoid nut that is Steve Jobs though...

[SOLGarion]

Even if a game gets through, they might pull it if they see someone using midi for non music functions. They have let stuff through before and then pulled it when thy realized all that it could do. I am looking at you idos.

[Craigix]

Even if a game gets through, they might pull it if they see someone using midi for non music functions. They have let stuff through before and then pulled it when thy realized all that it could do. I am looking at you idos.

Exactly. This is why I keeep saying don't expect it to work with anything other than the bare minimum of keyboard mode on non-jailbroken apps.

[torpor]

Oh, this is silly .. why on earth would they pull a game which uses CoreMIDI? The whole point of MIDI is that you can use external controllers with your application .. there is no such requirement that MIDI input only be used for making music - look at all the light-controller apps that are in the store already, they use MIDI for control inputs .. thats entirely the point of MIDI in the first place: to *allow* apps to be controlled by external devices.

All this paranoid delusional prejudging of "what will happen when Apple does _X_" is really just paranoid, delusional, prejudice. Of course, you won't be 100% certain, sure as rain, that you are right, until it happens - and the chances of that occurring are nill if you talk yourself out of it way in advance of actually, you know .. doing it ..

MIDI is *FOR* external control on iOS. That is what it is for. All other hacky solutions are going to get rejected, and if you make a point of promoting a technology that is not part of iOS as a solution to your hardware design dilemna, then for *sure* Apple are not going to play with you. But if you use their technology like it should be used - standardly, using sensible API's (MIDI is great for control), then you'll have a lot more progress ..