iGetIt! Music

Online music education courseware for non-musicians who want to learn how to write their own rock songs.

My Photo
Name:
Location: Austin, Texas, United States

This blog documents the development of JIMS iGetIt! Music System (JIMS). JIMS' goal is to help you Understand Music in 24 Hours™, if you are (a) a non-musician (b) who wants to learn how to write your own rock songs. Requiring no instrument other than your own computer, and without using traditional notation, JIMS is being designed to deliver a deep understanding of tonal structure...in just 24 hours.

Monday, June 14, 2010

HTML5 vs. Flash/Silverlight/JavaFX

Given that I've invested many months in teaching myself Flex, and have a professional background in technology evangelism, I'm fascinated by Apple's decision not to support Flash/Silverlight/JavaFX/etc in the iPad.

Why did Apple ban Flash (among other things) from the iOS?

John Gruber's insightful blog post, Why Apple Changed Section 3.3.1, cuts right to the heart of the matter, to wit, that this is a tactic to help Apple establish the iOS API as a de facto standard for mobile apps.

This is a very dangerous tactic for Apple. Tactics that are perfectly legit for a non-monopolist (such as Microsoft's Windows pricing policy) are retroactively illegal for monopolists.

Apple's market share of the mobile handset market, at just 2.7%, is far from monopolistic. However, in 2009, 94% of mobile apps were sold into the iOS market. That is, if you want to profit from sales of your mobile app, then you must release it on iOS, and therefore you must develop it according to Apple's dictates. That is pretty much the definition of monopoly power. Once Apple is determined to have monopoly power, tactics such as Apple's banning Flash/etc. are likely to be found to be retroactively illegal. (I cannot over-stress the importance of the word "retroactively" in this discussion.) This is the market that will capture the attention of anti-trust regulators.

An anti-trust inquiry into Apple's tactics has already been launched in the US; I would not be at all surprised to see one follow rapidly in the EU.

Apple's actions impose two new costs on itself:

  1. Direct costs: Anti-trust defense costs a fortune, in legal bills, fines, and―most importantly―executive focus.
  2. Indirect costs: Acting in a monopolisitc manner, as Apple is now doing, makes it appear to be evil. Apple has profited enormously from its warm and cuddly reputation, which it has now started ruining. This indirect cost is very likely to far outweigh the direct costs of anti-trust defense.

If Apple's actions succeed in establishing it iOS API as the de facto mobile app standard, however, then these costs can be easily borne out of the immense profits that it will make from the resulting vendor lock-in. Apple would be far more powerful than Microsoft ever was, because it would control

  • the central processing unit (A4, like Intel's x86)
  • the hardware (iPhone/iPad/iWhatever, like Dell+HP+everyone else)
  • the OS (iOS, like Microsoft Windows)
  • the app distribution channel (AppStore, like everyplace you ever bought software), and 
  • the software development tools (XCode, like Microsoft's Visual Studio and the open-source Eclipse tools platform). 

Apple would have proprietary control over the entire value chain...except for mobile apps, from which it would nonetheless extract a 30% tax via the AppStore. It would have the most comprehensive computing monopoly since IBM's.

Here are some relevant links:
Apple is attempting to cover two bases at once:

  • First, it is using the license restrictions on the iOS SDK (and related AppStore approval) to focus independent developers on the iOS API, thereby building a critical mass of support for it, and locking it in as the de facto standard API for mobile app software development, as described above.
  • Second, it is preparing for a future transition away from native (iOS or Android) apps to open-standards-based Web apps, in case its iOS-focused strategy either fails or dies a natural death due to the maturation of open standards such as CSS, HTML, etc. Hence, its aggressive support for those standards the open-source WebKit browser, on which Apple's Safari is based. WebKit is intended to ensure that if web apps emerge as the new de facto standard, no one else, outside of Apple, controls that API.

In short, Apple's "banning Flash" has absolutely nothing whatsoever with the technical merits of Flash; it is purely a platform play by Apple. All of Steve Jobs' comments regarding the technical merits of Flash are just smoke and mirrors, to distract attention from the core issue.

To further execute this strategy, I would expect Apple to take two steps:
  1. Implement the iOS API on top of Android, allowing Apple to sell its developers an iOS-to-Android app-porting tool. If this tool were expensive enough, the profit from it would more than make up for any "sales of iPhones lost to Android phones due to the availability of iOS apps on Android," while further locking in the iOS API as the de facto mobile standard. Establishing the iOS API as the de facto API for Android apps would emasculate Android as a competitive threat, by ensuring that any new APIs developed for Android would be ignored by developers...until wrapped by new iOS APIs. If Apple could also extend its mobile advertising restrictions to iOS-based apps running on Android, then the porting of the iOS API to Android could be even more profitable. Alternatively (or in conjunction), Apple could license the iOS to other handset vendors, and license the iPhone as a reference design. This alternative is extremely unlikely, however, given Apple's corporate culture and business model.
  2. Release, and feature, Apple-branded mobile apps in the best-selling and most-stable categories. Most casual users will favor the Apple-branded products simply because they are Apple-branded (so long as the apps don't suck). This will not only earn Apple additional revenue, but also give it a stable of in-house applications which can help drive future new iOS APIs to critical mass, and with which non-Apple apps will need to interoperate.



Both of these steps would increase the value of the iOS API standard to developers and consumers, thereby increasing its value to Apple and also locking it in even further.

So, what does all of this mean for Flash/Flex developers such as myself?
  • In the short run, Apple's having banned Adobe's Flash-to-iOS deployment tool is a pain. If I needed to sell my app to iOS users (which, thankfully, I do not), then I would have to use Apple's tools, framework, language, etc. for that version...which would not then be portable outside of Apple's universe. That is, I would be compelled to develop and maintain two codebases.
  • In the medium term, I would expect to see Adobe find workarounds (such as proxying Flash content onto the iOS as Opera Mini does), which will work just fine for many kinds of content (streaming video, for example), but not so well for some kinds (games and RIA's, for example).
  • In the long term, anti-trust action will almost certainly compel Apple to drop its development-tool restrictions.

And throughout this run, the only affected deployment platform is iOS―that is, Apple's mobile products. Flash continues to work great on Macintosh computers, and on all other computers; just not on Apple's mobile products.

Apple's tactic has slightly devalued Flash/Flex's cross-platform value proposition, but the demand for Flex developers has been rising so rapidly that Apple's tactic is a blip, not a barrier, to the monetization of Flex development skills.

Labels: , ,

Monday, June 7, 2010

Starbucks Via Ready Brew: taste-test

Yesterday, I received a sample of Starbucks VIA(tm) Ready Brew Colombia in the liner of my Dallas Morning Newsso I set up a blind taste test.

Bottom line: Starbucks VIA Ready Brew tastes like battery acid. We'll stick with Community Coffee Dark Roast.

The three contenders were:
- Our regular coffee, which is Community Coffee's Dark Roast (brewed in a Bunn BTX Thermo-Fresh Brewer)
- Nescafé Brasero, an instant coffee I bought on a recent consulting trip to Norway
- Starbucks VIA Colombia Ready Brew

The taste-testers: my wife Patti, her mother Gretta, and myself.

I knew which coffees were which, but Patti and Gretta knew them only as coffees A, B, and C.

First, we tried all three coffees black.
- Patti's preference order: C most preferred, then B, then A least preferred, with the comment that B was bitter, but A was worse.
- Gretta's preference order: C most preferred, then A, then B least preferred, with the comment that B was the most bitter.

Then, after adding sugar and half & half, they sipped again, were polled again, and gave the same preference orders.

They result: they liked their regular coffee (Community Coffee Dark Roast) best (coffee C), and were split on whether Starbucks (B) or Nescafé (A) was the worst.

So, we won't be switching anytime soon.

Scientific? Not even close.  Fair?  Absolutely. We were comparing the coffee we drank everyday to an alternative, which is exactly what Starbucks intended people do with its free samples.

If anything, our informal little taste-test made me look forward to trying the instant version of Community Coffee's Dark Roast. We already know that we like its basic flavor.  The VIA packet contains 3.3g (0.1164oz) of instant coffee, and they cost about a dollar per packet in bulk online, so VIA costs about a dollar per cup.  The instant Community Coffee Dark Roast, however, has a list price of $5.69 for a 7 oz jar, which (all else being equal) would make 60 cups, hence costing less that 10¢ per cup -- one-tenth the cost of Starbucks VIA. And, of course, Community Coffee's ground coffee costs even less per cup than that.

Apparently, Starbucks is continuing its business model of selling overpriced coffee to people with more money than sense (or taste).

Thanks for the sample, Starbucks! Now we know that our Community Coffee Dark Roast is not only less expensive, but also tastes better, than Starbucks.

Wednesday, June 2, 2010

Model, Conjecture, Hypothesis, Theory, Law

In science, what is the difference between a conjecture, a hypothesis, a theory, and a law?

The best answer I was able to find, through Google, I found here, written by Jeffrey Glassman (who was apparently paraphrasing Michael Riordan).  Here's the relevant section:

Science is all about models of the real world, whether natural (basic science) or manmade (applied science, or technology). These models are not discovered in nature, for nature has no numbers, no coordinate systems, no parameters, no equations, no logic, no predictions, neither linearity nor non-linearity, nor many of the other attributes of science. Models are man’s creations, written in the languages of science: natural language, logic, and mathematics. They are built upon the structure of a specified factual domain. The models are generally appreciated, if not actually graded, in four levels:
1. A conjecture is an incomplete model, or an analogy to another domain. Here are some examples of candidates for the designation:
“Ephedrine enhances fitness.”
“The cosmological red shift is cause by light losing energy as it travels through space.” (This is the “tired light conjecture.”)
“The laws of physics are constant in time and space throughout the universe.” (This one is known in geology as “uniformitarianism.”)
“Species evolve to superior states.”
“A carcinogen to one species will necessarily be carcinogenic to another.”
2. A hypothesis is a model based on all data in its specified domain, with no counterexample, and incorporating a novel prediction yet to be validated by facts. Candidates: 
“Mental aging can be delayed by applying the ‘use it or lose it’ dictum.”
“The red shift of light is a Doppler shift.”
3. A theory is a hypothesis with at least one nontrivial validating datum. Candidates:
Relativity.
Big Bang cosmology.
Evolution.
4. A law is a theory that has received validation in all possible ramifications, and to known levels of accuracy. Candidates:
Newtonian mechanics.
Gravity.
Henry’s Law.
The laws of thermodynamics.
Each of these candidates can stir arguments worthy of a paper, if not a book, and no model is secure in its position. Weak scientists will strengthen their beliefs and stances by promoting their models while demoting the competition. Some familiar models fail even to be ranked because they are beyond science, usually for want of facts. Candidates:
Creation science or notions of “intelligent design.”
Astrology.
Parapsychology.
UFO-ology.

One of the positive outcomes of the extremely public debate about anthropogenic global warming (and evolution/creation, for all that) is that it has compelled thoughtful scientists to re-acquaint themselves with the Scientific Method.  The Scientific Method is like democracy: the worst possible system, except for all of the others (paraphrasing Churchill).

I don't know whether Glassman (quoted above) is a credible scientist or not, but the whole point is that that's not the point: experimental results are the point, not the personality, pedigree, or popularity of the person who produced them (to be arrestingly alliterative).

JiMS proposes an alternative model for displaying, controlling, and understanding musical information. It is based on the Matrix's hypothesis that human cognition uses an isomorphic note-layout to classify and track tonal relationships over time.

The Matrix's hypothesis is, in turn, based on Sethares' theory that consonance arises from the alignment of tuning and timbre.

JiMS' hypothesis predicts that the cognitive map of tonal space observed by Janata, Krumhansl, etc. will prove to be tuning-independent across the syntonic tuning continuum—but to experiments have yet been performed to test/falsify/confirm this claim (which is why it's a hypothesis, not a theory).

I have every confidence that JiMS will prove to be the fastest path to deep musical understanding. But, what do I know? Until the courseware exists, no experiments using it can be conducted, so I have no supporting evidence...yet. Only time—and the application of the Scientific Method—will tell.

Labels: ,