Today, Apple released a beta of their iPhone OS version 4.0; in order to access the release and start developing their applications for it, iPhone/iPad developers were required to accept the following restriction:

“3.3.1 … Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).”

This is a fascinating and wacky position. Much of the outrage over the above statement is coming from developers who would like to use tools such as Adobe Flash CS5’s iPhone packager, Unity and others to create applications — these tools produce intermediate translations from their own representation of an app into a form that is at some level compatible with Apple’s own standards. With this restriction, Apple appears to be attempting to outlaw the use of such tools, presumably to monopolize not only the ends but also the means of iPhone development. One can only speculate on the possible reasons: an Apple/Adobe vendetta-in-the-Valley, a mistaken belief that consistent developer tooling means a consistent user experience, a desire to control every aspect of the value chain.

Personally, I think the outrage should be over the metaphysical angle here, not the business angle. Apple is implicitly taking a position that apps are not “originally written” in the minds of developers, in the form of cognitive representations of problems and their solutions. They are taking a position that the brain is not a translation tool for mapping from these representations into C, Objective-C, or what have you. They are subscribing to the theory of a “ghost in the machine”, implying that at some point an app crosses some magical boundary from being an mental thing into a physical thing that is “written” in some definite programming language. They are maintaining this because, if they weren’t, every single iPhone app would violate their licensing agreement by virtue of the developer’s mind itself being a tool that produces Objective-C as an “intermediary result”. Apple may thus be the first company to bet the farm on Cartesian dualism.

If this seems like a really nerdy joke (which it could be), try a few thought experiments. What if Ben writes a Flash app, shows it to Amy, who codes it up in Objective-C, compiles it and submits it to Apple? Should it be rejected since it was not “originally written” in Objective-C? If you think Apple’s answer would be “no” — a good guess — then substitute Adobe’s iPhone Packager for Amy. Now should it be rejected according to the rules? What, at the end of the day, makes Amy different from a machine translation tool? (Personally, I’d rather hang out with Amy than with iPhone Packager, but that’s another story.)

You may be thinking that what makes Amy different is that she could at least in theory translate the idiom of the original application to the idiom of the iPhone, which would provide a better user experience. Maybe so — so let’s look at another example. What if Ben’s application is an adventure game, and he wishes to describe the behaviors of the game objects and rooms using a simple scripting language that is translated to C as part of the process of compiling his game. He’s not using Flash or Unity or anything like that. Coding game-behavior scripts in C is a pain in the butt, and Ben’s a better programmer than to waste his time on that. He’d rather create the ideal one-off translation tool for the job. Sorry, Ben — clause 3.3.1 says that your program must be “originally written” in C, not translated to it. Maybe you should hire Amy to translate your scripting language by hand, that might be acceptable (since Amy will be “writing”).

Doesn’t this start to seem like backward progress, rather than forward progress?

Programs aren’t “originally written” in any definite language, or in any definite location. Programs are encoded information that is contiguous and continuous with the information in our heads, and in the world. Programs are often generated by other programs and tools, to which the same difficulties in definition apply. My programs are originally written in the shower — at least according to my definition. We could engage in a long argument about whether these shower-programs are really “code” or not, but my main point is this: it seems silly for a company like Apple to take a definite position on exactly what “originally written” and “intermediary translation” mean. (They declined to define these terms in the agreement, of course.)

I leave you with a final quote from the license agreement:

“10.4 Press Releases and Other Publicity. You may not issue any press releases or make any other public statements regarding this Agreement, its terms and conditions, or the relationship of the parties without Apple’s express prior written approval, which may be withheld at Apple’s discretion.”

Oops, close call. Good thing I didn’t click “Accept”.

Libby Freligh was the senior product manager for the Flex platform at the time of its introduction by Macromedia, and the Boston Flex User Group is lucky to have rounded up Libby as a speaker this coming Tuesday, October 13 at One Broadway, 5th floor in Kendall Square, Cambridge.

This won’t be a techie talk for a change: instead, this one’s all about the business landscape inhabited by Flex then and now. If you don’t know Libby, I can tell you this: she is a speaker with a lot of humor, intelligence and energy. Not only will you not be bored, but I expect you will be treated to some inside-type material about the origins of Flex that you’d simply never hear anywhere else. I think it’s fair to guess that you will walk away with a broadened perspective whether you are a technician, a business person or just plain curious.

Hope to see you there!

After months of waiting for an opportunity to open up in my schedule, I’ve finally managed to create and package the StandingWave2 audio synthesis engine for Flash. It’s now up on Google Code at http://code.google.com/p/standingwave/. Phew… about time!

People have been asking for an open source audio library for a long time. Because the original StandingWave1 became an integral part of Noteflight, I could not simply give the code away. StandingWave2, on the other hand, is a clean subset that the Noteflight team is happy to make available to the Flash community under the MIT OS license.

The basic ideas behind StandingWave are sources, filters and performances. Sources and filters are simple, self-contained objects that can be hooked up to create a kind of audio-processing/sequencing pipeline, and then rendered by a “player” object that encapsulates the Flash Player 10 audio API. Performances allow source/filter combinations to be delivered in a continuous sequence, with extremely precise timing. Obviously this can be used to play music, but it can also be used for all kinds of dynamic sound creation. And it’s relatively easy to extend StandingWave to add your own kinds of sources, filters and performances once you read the code and get the idea.

All the DSP algorithms are in pure AS3. They would certainly be faster in PixelBender or Alchemy, but we’ve opted to keep the approach simple and flexible for now so that it’s easy for people to extend.

I will be talking much more about StandingWave at 360Flex and Flash on Tap, so hope you can make it to either of those conferences. I’ll be posting the slides here.

About its quality and performance: as useful as this library is (thousands of people use it on Noteflight), it could be so much better. It’s fast, but it should be faster; it has a basic repertoire of sources and filters, but should be richer. The need for improvement is one of the main reasons we’re open sourcing it: we very much want others to contribute.

Happy audio coding!

Important update: After a lot of amazing work by Max Lord, who rearranged SW2’s internal organs to create a new, bionically altered library, StandingWave 3 was released in June 2010. This update to StandingWave uses Adobe Alchemy to compile C audio processing code directly into the Flash Player for maximum speed, and is generally much faster and more flexible than Standing Wave 2.  It also includes a notion of modulators that allows for continuous variation of many filter parameters.  Like this idea? I do, which is why it’s now the production audio library in Noteflight.  Go to the StandingWave 3 repository on GitHub.

I’m showing a few cool demos of this technology at the conference, including a Moccasin-based visual editor for a “musical shapes” world in which shapes represent tones, and a set of data entry forms that progress smoothly through an accompanying musical form as the user navigates. It’s been loads of fun working on this stuff, which is to say it’s not anything like work at all.

I guess I have to go back to work now.

Gosh darn it.

http://joeberkovitz.com/projects/FITC2009/BuildingVisualEditors.pdf

Overall, I am really enjoying this conference purely as a conference. It’s a much broader mix of creative and technical people than I usually see at software-related shows, the organization is great, and the quality of the presentations has been overall very high. A lot of the best Flash coders in the business are here, as are some folks from the Adobe Flash Player team. It’s a great bunch of folks to hang out with and talk to. As one highlight, it was nice to meet Robert Penner, a well-known name in tweening-weenie circles and one of the few other people who has worked on music notation in Flash (he did a lot of work on the mediaRAIN music viewer).

Toronto is a pretty hip and fun city too, as I am finding out. Maybe more on that later — although I didn’t bring my camera, stupidly.

Anyway, I just returned from biking in Arizona to find that Noteflight had been nominated as a Finalist in the FITC 09 award category of Technical Excellence. FITC has a popular-vote aspect of these awards in which people can vote for a set of “People’s Choice” winners, separate from the judging process.

I hereby shamelessly ask for your vote at:

http://awards.fitc.ca/pc/

If elected, I promise there will be a chicken in every pot, plus a quick, painless end to the recession through a new government-mandated sedation program.

I’ll be talking about the architectural adventures encountered in building Noteflight, the first full-featured online music notation editor. I’ll then talk about how some of the ideas used there have been distilled into the Moccasin open source framework in Flex. I expect that we’ll build a new feature into a sample graphical editor right on the spot, as a live coding example. Finally, I’ll show a little bit of RedLine, a new interactive site-building tool based on Moccasin that I created with others at Infrared5.

Hope to see you there!

As to the other problems plaguing Flash 10 audio on Windows, well, the jury is still out on whether those have improved with the new player.  We at Noteflight have been receiving a regular stream of support emails complaining about output not working on Windows.  We have typically been asking these folks to turn on a configuration setting that reverts the audio output approach to Flash 9-based APIs, which always makes their problem go away.  Now that the new player’s been released, we’re going to try a different approach and ask our users to upgrade to the new Flash Player.  If this works, we’ll be really happy that Adobe fixed some bugs affecting configurations found in the field, but not in our lab.  If this doesn’t work, well… brace yourselves for some more long, dissatisfied posts here.  I’m hoping for the best, though.