I think that by restricting Developers to a specific set of languages, Apple can somewhat ensure that developers target their platform specifically rather than have developers submit apps that are built for the lowest common denominator of mobile devices. I guess they don’t want to foster an environment that mirrors what’s on the web today. Most websites leave out a ton of features just because IE6 cannot support those features. I do believe that developers produce their best work when they target a specific platform and take advantage of the unique features that platform has to offer.

It is also good business for Apple to maintain a base of developers that are “married” to their platform. Imagine an environment where most iPhone developers migrate to Flash CS5. In such an environment, if Apple releases enhancements to their frameworks, developers would have to wait for Adobe to integrate those changes into Flash before the developers could take advantage of Apple’s improvements.

What if Google buys Adobe and decides CS6 will only come out on google chrome and Flash will only support Android? Apple and all developers that target iPhone OS get left in the dust!

Let’s face it, we always have a choice of mobile phones but when it comes to graphics applications, Adobe is a very strong monopoly. I’d be cautious siding with them on an issue such as this. It may not end well. How much is the web premium suite again? Do you think we would have to pay that much if Adobe and Macromedia never merged?

Adobe is a behemoth. IPhone devs may not be able to use Flash but I’ll bet my last dollar that 99.9999999876% of all graphic content you’ll see on Apple, Sony, Microsoft, Palm & Android devices as well as the web will be created using Adobe’s tools. Isn’t that enough?

I don’t necessarily have an issue with Adobe’s goal of making flash an indispensable tool but I do think that a lot of comments in the blogosphere wrongly suggest that Adobe may have altruistic motives. Adobe’s goal isn’t to give developers choice; it is to maintain and extend the dominance Flash currently enjoys. Apple’s goal isn’t to limit developers choice but rather to ensure that their platform doesn’t become just another deployment target for Flash.

Consider the following: 
If a developer uses Flash, who becomes responsible for performance tuning? The developer or Flash? 
My guess is Flash.

If Flash achieves 65% penetration into the iPhone development market? Who becomes responsible for how efficient Flash generated byte code runs on iPhone?
My guess is Apple because end users will not attribute sucky performance to Adobe but to Apple. 

Both companies are right so there really is no need for Adobe evangelists to pretend this is a fight about open vs closed.

I bet the blogs on here will have a totally different tone if MS/Google/Apple release free tools that allow developers to deploy their apps as Flash files. We will not hear all the clamoring for choice on the developers behalf.

Take a midi packet with 3 bytes in hexadecimal notation such as 99 3C 64. This stream encapsulates the following instructions:

Play middle C on channel 10 at velocity 100. Now lets strip it down to nibbles & bits.

9 -> Note on message. (Examples of other status messages are: 0xB for controller change, 0x C for program change & 0xE for pitch-bend)

9 -> Middle channel 10. (Range 0 -15)

3C ->Middle C -> Note 60

64 -> 100 in decimal

Determining if a stream begins with a status byte.

A set high-bit on the first byte identifies the byte as a status message. This can be accomplished visually by converting 99 from hex to binary 10011001,  and seeing if the first bit is 1. This can be tested mathematically with the following condtion:

0×99 > 0x7F

Once you have determined that the byte actually sets a status, you need to identify the actual status that is set. Some examples of status messages are: 0xB for controller change, 0xC for program change & 0xE for pitch-bend. To get the value of the left nibble, you can use the following expression.

0×99 >> 4 (Shift the 4 places) or 0×99 / 0×10

Determining the midi transmission channel.

The second nibble (99) of the first byte in the stream, represents the midi transmission channel. Channels are 0 indexed so they range from 0-F in hex or 0-15 in decimal. So we can tell quite easily that the transmission channel in our stream is 10 just by adding 1 to the second nibble. We can extract the 2nd nibble using the following expression:

0×99 % 0×10 (% = modulo)

and get the midi channel by adding 1 to the result

(0×99 % 0×10) + 1

Determining the note number and velocity.

These are pretty simple. Just convert the Hex values to a decimal values

0x3c = 60

0×64 = 100

I’ll post my parser here when I’m done with it this weekend.