The reason for this is that I have been doing work on iOS and would like very much for their to be a supported way to communicate with the corresponding devices (iPhone, iPad) at speeds that are suitable for live gigging. Since, as I wrote in previous posts, I don't believe WiFi offers that performance I have been on sort of a quest to get the best technology available to help me.
Until iOS 4.2 there was no MIDI support at all in iOS save for the Line 6 MIDI Mobilizer which I believe has its own special software. With 4.2 the basic Mac OS X MIDI interface API became available for iOS. Along with this, on the iPad at least, came the Camera Connect 30-pin Apple to USB conversion adapter that allowed some USB MIDI devices to be connected directly to the iPad (the Camera unit does not work on the iPhone - I suspect because the iOS device battery is driving the MIDI unit and for iPhones the batter would die too quickly to suit Apple).
Not wanting limitations with my development effort, including performance limitations in getting data from the iPad to elsewhere either as MIDI or otherwise I found that I had to create my own, "Gold Standard" solution. My solution, which so far out performs all other USB/MIDI apps available for iOS allows me to play MIDI (or do virtually anything else I can do over a wire) at full USB speeds. Its Mac OS X (though it would work on Windows or Linux as well) software that allows me to simply connect my iOS devices to my Mac via USB and talk to them at full USB speed.
So far the best benchmark of performance has been this: generating continuously variable MIDI CC messages on an iOS device in a tight loop, i.e., while a finger is dragging. For virtually all devices save my "Gold Standard" USB solution the devices cannot keep up.
Which brings me to the iConnectMIDI. Mine arrive a few days ago from Sweetwater.
The first thing I did was tear it apart to see what makes it tick. Here it is out of the box:
It has three USB port - two minis (D1 and D2) and one regular "A" USB along with a power light and an activity light for each of the type of different connectors.
There are two full MIDI ports on the back. It uses a non-standard 5.2V 800 ma power system (musicians prefer 9V) also on the back:
Inside the guts the iConnectMIDI uses a TI Stellaris (LM3S3749) ARM programmable controller and a set of three SILabs F321 USB 2.0 controllers (link) for each of its three USB ports (one regular, two mini).
Mine is serial #0x1B (27 if you don't speak hex).
The web site talks about the huge performance boost this device has over standard MIDI (which runs at 30K baud or about 3 Kb/second). The 30K baud speed is based on ancient UART technology used in modems - save that MIDI runs a 0..5V signal. The web site claims 12 Mb/second of transfer speed (see this) - significantly faster.
So I've played around with this for a day or so trying to see what it will do and not do.
Here are my results so far.
USB port (A wude) connector does not meet the USB MIDI specs for the iPad to talk directly to the iConnectMIDI like E-mu X-midi 2x2 (see this site for a full set of compatibility issues and devices). This means that the iPad via the Camera Connector Kit does not recognize this device as a MIDI device.
(It would be nice if the iConnectMIDI did present its USB ports as iPad compatible. This has to do with some sort of standard for MIDI USB devices and whether a particular device follows that standard or not. The key here is "class compliant" USB MIDI.)
The iConnectMIDI (iCM) does, however, come with its own special Apple 30-pin to USB mini cable that magically works when plugged between the iConnectMIDI and the iPad. (I think this cable is were all the real magic is happening but I am not sure how at this point.)
I have been using Native Instruments Kontakt 4.0 quite a bit for testing the 3i (for reason which will become clear in later posts).
Connecting multiple different MIDI-producing apps to the iCM via USB does not drive Kontakt (iPad -> iCM D2 mini-USB, iCM D1 mini-USB to Mac, Kontakt set to use iCM D1 port which appears in the Kontakt options area).
However, by renaming the iCM D1 port on the Mac with MIDI Patch bay to something else, e.g., "iConnectMIDI ICM USB D1 - > Frank", does work if Kontakt is set to use "Frank" as a source of MIDI.
Most interestingly, if I change the iPad over to use the Apple Camera Connector and something like the E-MU which is known to support the iPad USB MIDI then it does work. This implies that when the MIDI commands go through two SILABS F321 chips something is getting lost or munged along the way. If the MIDI goes through only one by sending it through a MIDI connector (I do not think the F321s are involved in that signal chain) it does work.
(iCM - if you are listening this is a relatively serious issue...)
The same connection that does not work with Kontakt 4.0 does indeed drive Apple Logic correctly as well as MIDI Monitor. This tells me that its probably at least in part a Kontakt issue but I don't see them fixing it any time soon.
The 3i names its MIDI ports on the Mac similarly to that of the iCM so I am not sure what this issues is - it does not to me appear to be name related though name length could be involved.
A more interesting test was to hook things up using full USB and then blast away with MIDI CC messages at full iPad bore.
As I said above my USB solution works sending these messages at full blast. However, the iCM, for which I expected to see the same results, did not perform nearly as well. It seemed like the iPad overran the iCM causing it to store a few seconds of CC commands and flow them out at a much slower pace.
However, after some thought I suspect that actually this is an iPad MIDI issue and not an issue with the iCM. I think what's really happening is that the iCM is somehow magically tapping into raw iOS MIDI on the 30-pin port with its magical connector. The iPad MIDI driver is what's actually throttling out the MIDI CC's based on some sort of internal mechanism.
The iCM (and I base this on observing the lights) is just getting them at this much slower rate.
(MIDI has not flow control so I suppose this makes sense.)
From my perspective this is very unfortunate because it means that the iPad is limiting the speed with which it can send MIDI to around 30K baud - no doubt to conserve battery life.
Why Apple chooses to inject these interesting little limitations on these devices is beyond me. It would be nice if the MIDI were really fast - it would be more flexible that way. Even nicer if this was a API controllable issue.
But this limitation really means that even if the iCM has the 12 Mb/sec of bandwidth the marketing literature talks about you're just not going to see it in the signal chain from you iPad. So if I were iCM I would be bitching up a storm at Apple because clearly they are in at Apple to know the magic for the 30-pin connector yet the iPad and iPhone (though I haven't tested it yet) are throttled!
(Again, I understand that older equipment has limitations but this is just ugly. I guess too that the iCM probably does not have much memory and hence is happy that the iPad ensures that there never will be a buffer overrun.)
Imagine, for example, I want a volume slider on the iPad and I want all the volume messages to go through because I am using it like whammy bar or something where the results need to be relatively continuous. Certainly this prevents that and yes I know I can quantize my volume messages so there are fewer but that's not the point.
Why create an iPad that's clearly very fast computationally and supports USB 2.0 very well and then nail on a fifth performance limiting MIDI fifth wheel made out of old, rotting timber? Sure the MIDI standard limits speed to 30K baud - but don't hard code it because some devices might work faster - like your own!
For the money this kind of makes the iCM a pricey fifth wheel, especially when I can buy things like this USB MIDI at Amazon for $5.00 USD - for $10 bucks I get as much bandwidth.
I was really hoping for that 12Mb/sec of MIDI throughput to include the iOS devices...
Foiled again!
I guess its back to the Gold Standard....
No comments:
Post a Comment