Yesterday, I talked about two complaints of music developers writing applications for the iPhone. These come from developers who are really iPhone fans, who just want to get their software released and (for many music devs) better categorized on Apple’s store. Pajamahouse Studios, maker of the new Sonorasaurus remix application, follow up with a more detailed explanation of their situation.

These are not rejections; at least rejections are generally accompanied with some sort of suggestion of what would need to be changed. They represent the dreaded iPhone developer “limbo,” in which an application is neither rejected nor approved. For Sonorasaurus, that’s been the state of affairs for over two months. As the developers explain, there seems to be nothing unusual about their app:

• Library access: It doesn’t access the iPhone/iPod music library. (no application is allowed to do that, which incidentally limits a lot of the DJ app possibilities of the device) Clarification: The status of the music API itself is unclear; some developers report just this sort of approval delay when trying to use it. [Source] Also, access to files inside the media library is not directly possible, which can be compared to the status of Android.
• File access: A separate http server is provided, with a parallel library, for users to store their own tracks – again, something found on numerous other approved applications. This doesn’t use the included library.
• Included music / music distribution: Five included songs are for testing only – something found in a number of other, similar applications that have been approved. The application is not an alternative to iTunes for distribution.
• Media decoding: Custom MP3 decoding technology – something not provided on the iPhone – was separately licensed. Clarification: This was not meant to imply that you can’t do MP3 decoding; the developers meant to make the point that they were not violating patents or licensing by using their own decoding, which presumably they did for the purposes of building a DJ app.

Of course, whatever the reason, we’ve seen in past applications suddenly approved after weeks or months, so who knows what will actually happen with this app.

Read the full explanation:

In Limbo Pt. 1 [Sonorasaurus]

While reading that, though, I also have to observe how significant these workarounds are. Without launching into an Android versus iPhone debate – believe me, there are many, many things to criticize about the Android as a platform, especially relative to music –  none of these is an issue on the Android. Forget platform wars or fanboys. Alternatives are good. I’d hope that we do have more than one approach to how to do this. These approaches should have to compete with one another, as they offer different tradeoffs and advantages.

If music is becoming an application, this kind of freedom is important.

Point by point:

• Library access: Android’s standard, supported APIs provide access to the media library and user playlists. Clarification: this includes direct access to the files and the ability to read from the buffer of these files (with some effort), in public, documented, approved APIs, with no chance of having an app rejected for the use of these APIs. My understanding is that this is not exactly the case on the iPhone.
• File access: Users are free to put files on their SD card over USB, and off-load those files – neither possible on iPhone. And yes, these will be integrated with the media library; iTunes-style sync isn’t necessary.
• Included music / music distribution: Including songs is actually a bit of a challenge, but you can freely download content and store it on the SD card. Because Google doesn’t have an equivalent of iTunes, that includes creating your own alternative distribution methods – meaning a label or music store can do make their own outlet.
• Media decoding: Decoding technology is included on the phone, including the ability to decode the open OGG Vorbis format. Clarification: Some folks read this to mean that the iPhone can’t decode MP3s, which was not what I intended; the key point here is that Android has in-box support for free formats and byte-level access to the audio buffers they give you, by default, straight out of the user’s media library. That is not entirely the case on iPhone.

Beneath all of this is the major fundamental difference, which is that you can install applications for Android whether or not they’ve been approved for Android. There’s actually a checkbox in the Market that allows you to opt into installing other apps you’ve downloaded directly from a developer or from another source.

Again, I don’t mean to make a pro-Android argument. In fact, I believe many of these items are also true on Windows Mobile, Symbian, and upcoming Linux platforms; I just happen to be working on Android now, so I’m more familiar with it.

What’s important is that this represents an alternative approach to how to provide music as an application, one in which the user is free to load content on and off the device.

Specifically, this paragraph jumped out at me:

Another problem would be that Apple could see this as a means to circumvent iTunes as a means to sell and distribute music. This we also addressed. These songs can only be used within the App. They can not be removed from the app / device for use elsewhere (iTunes on the desktop, burning to a CD, etc).

Now, we hear from many developers that the iTunes integration is something that attracts them to the platform. Likewise, many content creators will want just these sorts of restrictions.

But what if you want fewer restrictions? Let’s say you’re an artist releasing Creative Commons-licensed tracks, and you want to encourage remixing, sampling, modification, and free use of your tracks. Or what if you’re a label or artist collective, and want to experiment with new ways of using mobile for distribution, beyond what’s possible with iTunes and Apple’s stores? The same qualities that may attract someone else should, I think, concern you. I don’t think that necessarily means you shouldn’t write an iPhone application with your music, but perhaps you should also consider trying an alternative platform.

There seems to be a growing sense that the iPhone Way is The Only Way. Obviously, that’s not the case. This very debate demonstrates just how much room for interpretation the distribution of content can produce.

A powerful DJ application for your iPhone or iPod touch may be a tantalizing prospect. But several would-be candidates aren’t available to you yet. Why? They’re languishing in Apple’s approval process, with no sign of whether they’ll be released or not.

For all the success of Apple’s App Store, some developers and users continue to express frustration at what they believe is a sluggish, unpredictable approval process, restrictive Apple policies, and Apple’s complete control over distribution and categorization. That now leads to two complaints from music developers. A number of music developers want more delineation from Apple’s categories, so that the flood of general music apps don’t drown out powerful, creative tools. Meanwhile, developers of DJ applications claim that Apple is discriminating against DJ apps, which they say has led to delays without explanation.

“Open” development is relative, without question. Game system makers require developers to prove to them why they should be “allowed” to create titles, leading to a tightly-controlled stream of approved titles. But the success of Apple’s relatively open development model has prompted many software creators to hunger for greater freedom. I’ve increasingly heard people enthusiastic about the more flexible distribution model on Google’s Android (and other Linux) platforms, which allow users to install apps they want. I even moderated a mobile music platform panel at the CMJ music conference at which a Verizon representative, no less, talked about wanting to be more open to applications. The benchmark was Apple, for being perceived as overly restrictive.

iPhone/iPod touch developers, however, aren’t simply ranting against Apple. They’re complaining because they’re enthusiastic about the App Store. They want changes from Apple and believe there’s potential to get what they want. That said, I think they also illustrate potential for rivals like Google to outdo Apple – assuming those rivals invest more time and effort into courting these kind of applications.

Is Apple Blocking DJ Apps?

First, some developers believe that Apple is intentionally blocking DJ applications from being approved. Whether intentional or not, a number of potentially ground-breaking applications are unavailable after a significant delay. Kasabian Kasabianmeister writes:

Apple is deliberately not allowing DJ apps to the App Store

Something really strange is going on with the Apple review team. They now seem to approve all kinds of applications, even the ones that have been previously considered "unacceptable", but there is one kind of applications that are simply kept "in review" stage for months without any explanation.
http://www.youtube.com/watch?v=tVv4PY6st6Y

These are the DJ applications that have been developed with the idea to give the user the ability to mix his own MP3 tracks on the iPhone. Currently, there is no application in the AppStore that has such functionality. Of course, this wasn’t left unnoticed by the developers, but…

At least 3 applications: Touch DJ (www.amidio.com), Sonorasaurus (www.sonorasaurus.com), DJ Player (www.djplayer.fm) are not being approved since the beginning of September, hitting the 2-month "in review" mark. One of the developers even made a video voicing the frustration over the absolutely unacceptable behaviour of Apple:
http://www.youtube.com/watch?v=jDUS_2rcAjw

What is really weird and unprofessional, Apple doesn’t give any reasons whatsoever what is the reason of such delays. The developers are just told to "wait" without any explanations.
Meanwhile, the demand for the DJ apps is so high that people even started an online petition entitled "Apple, Allow DJ apps on the iPhone!":
http://www.petitionspot.com/petitions/iphonedj

One of the reasons for such attitude could be that Apple is working on its own DJ app, or is waiting for a DJ app from a "senior" player and keeping the possible "competitors" aside. In any case, it is quite possible that we will know the real reason soon.

It’s worth noting that, in the past, Apple’s application process has simply proved to be inconsistent and slow, which can cause people to see intention where there is none. But that doesn’t necessarily excuse Apple’s App Store approval process. The iPhone and iPod touch are popular largely because of Apple’s success at making media playback devices. Apple needs to document what it views as acceptable use of these devices. In the absence of information, developers are jumping to their own conclusions, possibly accurately, possibly not.

Obviously, aside from interest in Apple’s policies, I’m sure many iPhone and iPod touch owners are eager to see these applications, so we’ll certainly be following them to see if any are released.

In other rejection news… The App Store is currently just letting these DJ apps languish in limbo rather than providing a rejection. But another significant set of rejections is game titles built with the Unity game engine. There, the issue appears to be the presence of support in the engine for a private API call from Apple, whether or not the title itself uses the API, and …uh, yeah, that one’s complicated. Updated TUAW tells us via Twitter that Unity developers say they’ve fixed that issue, so… move along, nothing to see here.

Do Music Apps Need Better Categorization?

One potential danger of having a centralized store like iTunes and the App Store is giving control of approval to a single company (Apple), as seen in the DJ apps. The other is that such a storefront will simply not be categorized in a way that allows people to discover apps successfully.

Apple has been roundly praised for creating a store that encourages people to consume apps. Now, some developers want Apple to tweak their categorization to allow some of the most creative applications to stay in the forefront. Over the summer, Jokton Strealy, maker of the excellent songvoo music collection management tool, issued a call to fellow developers to try to get better categorization from Cupertino.

Side note: songvoo is just the sort of app that critics of the App Store might assume would be impossible. It replaces the existing playback functionality of the iPod and iPhone, the sort of replacement app that has sometimes earned rejection from Apple. Evidently, if an application is differentiated enough, it can clear Apple’s approval hurdles. (On the other hand, inconsistent policy and overzealous restrictions are at the center of some of those criticisms.)

But Strealy has no complaints about the App Store itself or the approval process. He just wants a more intelligently-organized store. Here’s his open letter from the summer, which has since earned a lot of support from fellow developers:

Recently, the Music section of the App store has gotten very busy with a new type of app — let’s call them Artist Apps or Fan Apps. Some of these Apps are great resources for fans and artists reaching out to their fans and potential fans, and some don’t live up to their potential.

However, they are joining a category that previously moved a lot slower, as the apps that had been populating this category were apps with a lot of development put into them and therefore sold at a higher tier usually- but were released at a slower pace. A look at the top 100 paid music apps illustrates this nicely.

Customers perusing the music section to catch that next great sound generating tool (for example), could check in on the new releases section perhaps once a week or even once a month and have the opportunity to check out all the great new apps that had been released, without worrying that one was missed.

Now however, these newer Artist apps have flooded this category, and great apps are getting lost in the shuffle. On one day last week, there were 21 pages of Artist or Fan apps, with a few "other" apps strewn in the mix here and there, very hard to pick out of the jumble.

I understand that this may be happening in other categories for other reasons, but I only concentrate on the Music section since I am a music producer and music App writer.

I propose that we all get together to come up with some suggested sub-category names for the music category. I will start the list off and hopefully some of you will chime in and give suggestions for other categories or add more definition to a sub-category that is already here.

Once enough input is received, I will compile it into one bug report for Apple. i will then post the bug# for everyone to include with any correspondence with Apple on this issue.

New sub-categories for the Music section of the App store.

Music Creation:
Synthesizers, drum machines, sound generators, scoring and notation, sequencers, DJ apps, recorders (multi track)

Music Utilities:
Lyrics apps, iPod interfaces, visualizers, iPod controllers, song recognizers, concert finders

Learning:
Metronomes, guitar and voice tuners, music slow downers, guitar tutors, chord apps,

Artist Apps/Fan Apps:
iLike apps, Deadmau5 app, PVD App, Underworld App, NIN, etc.

Radio Tuners:
AOL Radio, Pandora, Last.fm, individual radio stations

Please visit the Apple iPhone developer forums and voice your opinion/support!
https://devforums.apple.com/message/107989#107989

Sincerely,
Jokton Strealy., President
Elements2Dance.com

If nothing else, the explosion of development for iPhone and iPod touch is prompting some lively discussions about just what development should look like. A lot of what you hear is praise for the Apple model, but I expect some of the criticism of it – even down to minor details – could be productive, as well. I’ll certainly be watching the development of both of these issues, and we’ll see if Apple responds or not.

Updated: Jokton notes an additional change to the way apps are listed.

As for my original issue with categories and release dates, there has been a new development. Apple recently stopped listing “updates” in the “release date” listing of each category. Now the only way to get a listing there (which generates sales) is release a new app (1.0). Before that, devs were releasing constant updates to an app to keep it “on the radar” on the app store, even if the update were a simple as correcting a spelling error or perhaps even faking issues to correct. That in itself created a lot of “update spam”. Many developers are up in arms about these new changes because previously this was the only way to get your app seen by the masses. There has been no official word from Apple on the issue, so it is still unclear if this is a permanent change or some kind of error in the system. If this change is indeed permanent, then the argument for more subcategories is even more important now.

Critics frequently attach the phrase “lock-in” to Apple’s iTunes Store – iTunes – iPod/iPhone combination. But, in the post-DRM age, what does that mean, exactly?

First, you have to recall that while for many of us the manual drag-and-drop music management is appealing, it isn’t so for many average consumers. They want sync. That means that music will be stored in iTunes and synced to Apple devices and nothing else. Apple is serious about locking you to their store and their devices, enough so that they frequently update their software with special keys that prevent the use of devices. iTunes is “free,” but Apple determines which mobile devices you can use and which you can’t. And Apple has gone after anyone who dares give you the ability to use your own music software or own devices, including efforts (ironically) to make their iPhone and iPod work with Linux and open source players.

These efforts don’t protect the music or prevent privacy – they protect users of Apple’s software and mobile devices from using anything but Apple’s tools. Yet Apple has used the Digital Millenium Copyright Act to take legal action over anyone who dares to even talk about how to use legally-purchased music and hardware:

OdioWorks v Apple

Perhaps suspecting their case was too thin to defend, Apple eventually backed off that particular claim — after, says the Electronic Frontier Foundation, “7 months of censorship and a lawsuit.”

Apple Withdraws Threats Against Wiki Site

But the software and hardware locks are unchanged. And Apple has won, in my view, an even more important battle: they have a monopoly over mindshare.

Here’s an example from a recent review by Gizmodo of the Android 2.0 mobile operating system from Google, as implemented on the Verizon-distributed Motorola Droid. They have some fair points about Android’s maturity and strong and weak points. But note what they say about music sync:

The only way to get your music and videos on the phone is to manually drag and drop the files. There is no syncing, no easy way to get your music library onto your phone. How are normal people supposed to figure this out? Verizon reps actually joked about how putting music on the Droid is sure to make for a lovely Saturday afternoon. What. The. Shit.

In fact, this is technically accurate, to my knowledge, only if you’re using iTunes. That incompatibility is engineered specifically by Apple. It’s a “feature”: other vendors could make other devices sync with iTunes, but Apple engineers regular updates to prevent them from doing so. In fact, while Apple was conceding defeat in its efforts to censor the Web over its iTunes lock, it was simultaneously busy blocking the Palm Pre from working with iTunes. This should be especially sad to long-time Mac watchers, who saw a Mac community railing against Microsoft’s effective office software and operating system monopolies in the 90s. Those Mac historians should also recall the early development of iTunes and shareware predecessor SoundJam, both of which worked with a variety of hardware. Now, some members of the same Mac community cheer market share numbers and anti-competitive practices by Apple.

But, engineering aside, it’s really the mindshare battle that’s most impressive. Gizmodo, in saying the Android “doesn’t sync,” really means that it “doesn’t sync with iTunes.” And given iTunes’ massive market share, Gizmodo is not alone – I’ve seen similar complaints from other press outlets and, anecdotally, many, many users.

In fact, Android sync is supported by a variety of applications. In my tests, it works with the open-source players Songbird (Mac, Windows, Linux), Banshee (Mac, Linux), Rhythmbox (Linux), Winamp (Windows), Media Monkey (Windows), and yes, even Microsoft’s own Windows Media Player. Microsoft may restrict the use of its Zune media player, but ironically its music playback software is far more open than Apple’s.

By “sync,” incidentally, I mean automatically – it’s no harder to use these applications with Google Android than Apple’s iTunes and iPhone/iPod. I personally find most of them more flexible and intuitive than iTunes. And I can show someone in a couple of minutes how to manage their device via the file system, too – even “normal people.” (I definitely don’t count as “normal,” so no argument there. But presumably “normal people” can learn to use the Mac Finder, right? Apple certainly argues they can – then locks users out of that tool when they connect an Apple mobile player.)

This is not a pro-Android argument, despite the screenshot. Any music player or phone that supports normal disk mounting will work the same way.

Why should all of this matter to musicians? The reasons monopolies are a concern in the first place has to do with pricing, and media monopolies add to that control of culture and speech. Even if your music isn’t distributed through iTunes, pricing and consumption patterns, and even the kinds of music people listen to and where they discover it are now being deeply impacted by Apple. Apple, in turn, by convincing users that there are no other options and engineering interoperability out of their products protect that control, just as digital music is growing by leaps and bounds. (For statistical evidence of the resulting trends, see today’s other story, linked below.)

I spoke to the Electronic Frontier Foundation’s Senior Staff Attorney Fred von Lohmann in April about the paper-thin (literally) arguments from Apple, when Apple was trying to prevent websites from talking about the database lock between iTunes and mobile devices:

All Apple has told us about this is in the letter they sent to us in December, as posted on the website as an exhibit to our complaint. Apple simply cites the fact that the iTunesDB page authors said that the obfuscation mechanisms used to create the iTunesDB has “may reside” in the FairPlay DRM code.

…The important thing here is that the iTunesDB pages were simply discussions about what might need to be done to reverse engineer the iTunesDB hashing. There was nothing to indicate that the efforts had succeeded. So even if understanding the iTunesDB hashing mechanism somehow magically unlocked all of FairPlay (which would seem to be far fetched), nothing on the pages suggests that the authors were anywhere near that goal.

Note that at the time, the EFF did not claim Apple lacked the right to make these kind of locks. The EFF told CDM at the time, “They have every right to do – to try to block it. Apple can certainly try to block it. What they can’t do is use inapplicable federal law to use legal threats to get them to stop.” And Apple backed off those claims.

The issue is whether you should invest in a product that limits your freedoms to use it. And the issue for musicians is whether this kind of a behavior from a company with an effective monopoly is limiting the potential power of digital music listeners in the future.

This is not to say that there aren’t reasons to choose to use an Apple device or its iTunes software. As reader “low resolution sunset” says in comments on the previous story:

This is pure conjecture: but I tend to think that slick interface design, trust, and loyalty for the Apple brand identity is what’s winning them the dominant market share of downloads.

Indeed. So, why not rely on that design, trust, and natural loyalty? Why force loyalty through engineering? And even given these qualities, isn’t there a danger when one company becomes so dominant that people don’t so much as consider alternatives? What’s to keep Apple competitive on good design if they have no competitors?

I certainly can’t answer those questions. And in the meantime, I’m looking to other alternatives, alternatives that have made me quite happy.

More on what this can actually mean:

Digital Sales Up, But is Apple Monopoly the Price? NPD, Mint Data, Editorial Analysis

Part of the beauty of the iPhone from its launch date was the notion of a Mac you could fit in the palm of your hand. That makes it ironic that, for so many developers, mobile platforms in general have turned into a way to fragment software, to make it run fewer places instead of more. There’s something to be said for designing to a specific mobile device, but on the other hand, how many developers would want to restrict where their creations run? And particularly in music, isn’t the appeal of mobile creation the ability to have your tools work in more places? Maybe targeting just one gadget is the right choice for a given tool, but it shouldn’t be the only choice.

On the iPhone, the application Thump has plenty in common with a range of mobile music making tools. It’s simple but fun, a groove box with sequencing, subtractive synths, drums, and a set of basic effects, plus the ability to load your own samples and export songs.

Thump also demonstrates how simplifying sonic capabilities can produce musically-beautiful results, by focusing on the essentials and creating something with personality. Here’s a track by its creator showing off its sounds:
thump soundreel by mazbox

Well worth checking out the app on your platform of choice:
http://www.mrkbrz.com/thump/

What might not be immediately apparent is that under the hood, Thump makes use of the open source environment openFrameworks. As a result, the same code runs on iPhone, Mac, and Windows, as well as Linux. (It’s not distributed for Linux, but it could be. Hint, hint.) Creator Marek Bereza gives back, too – he ported the openFrameworks audio library to the iPhone, where it’s available to anyone.

Updated Marek notes in comments just what this means. The video below is, essentially, the same app. In place of the iPod screen, he has used a massive lattice of physical controls. A separate installation at the same show used a large touchscreen and simplified interface. And this really demonstrates what cross-platform means. Guy Kawasaki in the 80s mocked “ports” as a cheap wine. The idea is not to simply dump your code on a different platform and hope for the best – in fact, in this case, the changes from one platform to another were radical. The key is maximizing what’s essential, what really is not specific to a single device.

Physical Sequencer from Marek Bereza on Vimeo.

Creative Applications has a detailed write-up of the installation with more documentation.

If you’re interested in creating your own projects, oF has an elegant syntax based on Processing, but adapted to C/C++ coding paradigms and libraries.

I would recommend trying desktop development first as you’re learning, but when you do want to go mobile, setup is absurdly easy:

Setup instructions for iPhone

Having this as a foundation means more freedom for users and developers alike, the ability to run where you want, and a shared community of artists helping one another out. It does not mean sacrificing revenue, either – which is important, because revenue is often what enables (and encourages) developers to make new things. Here, we see a commercial mobile tool and distribution via the iTunes store, with free-as-in-beer distribution of desktop apps. But even the Free Software Foundation actually encourages charging for distribution – and to many people, the FSF is the most extreme example.

The bottom line is, you’re free to create what you want, where you want – and it doesn’t even have to have a price of free.

The use of openFrameworks is possible because the iPhone allows the execution of native code. Apple does not allow the Java virtual machine, which locks out many useful platforms and tools — including Processing. Naturally, that should not be the case with forthcoming non-Apple platforms based on Linux; more on that soon.

Thanks to Memo Akten for the tip — and for his exceptional documentation of iPhone openFrameworks development.

GPU-tiful and Cross-Platform

Updated Another framework I left out is the lovely libnui. The tagline says it all: “C++ API, multiplatform (Mac OS X, iPhone, Win32, Win64, Linux), 3D hardware accelerated GUI and more…”

On the iPhone, Intua’s elaborate Beatmaker software and David Wallin’s bleep!box have both been made with libnui. I want to single out bleep!box because of its UI – note how UI elements are simplified and scaled to the size of your fingertip. That’s something that, speaking of multiple platforms, could be equally important with touch hardware coming to Mac, Windows, and Linux platforms (some of it here already). I saw a huge fan of Windows tablets loving Propellerhead Reason on a tablet. He probably would be less enthused running Reason or Record on a touch interface; the UI elements are way too small.

bleep!box is also worth a look for the same reason as Thump: elegant UI, simple functions, and a lot of fun.

Pd, too

Pure Data, the open source patching cousin of Max/MSP, can also run on mobile devices. It’s currently powering the application RjDj, but because Pd is free, that could be just the beginning. In May, I wrote about the work being done by Hans-Christoph Steiner, who has been porting Pd even to ancient PDAs and iPods – including those, notably, without native floating-point capabilities (the kind of number crunching usually associated with sound).

Well, now Hans-Christoph is looking toward other, current-generation devices, too, kicking off with a workshop on making interactive sound on the iPhone using Pure Data. Here’s a taste:

OK, kids, you won’t believe how easy this is. Once you have Pure Data installed on your your iPhone or iPod-Touch, creating and uploading your own sound-processing and sound-generating patches is as trivial as copying a text file to your device! You’ll still need an Apple Developer License, but because Pd patches are treated as media files, they don’t have to go thru Apple’s elaborate code review — so, you can just dive right in, turning your phone into a pocket synth within minutes. In this 3-hour hands-on workshop, interactive sound whiz and Pure Data developer Hans-Christoph Steiner will lead you through all the steps.

Hans-Christoph will be talking Pd on the iPhone at a conference next month at Carnegie Mellon University in Pittsburgh. That will also include Memo Akten and Zach Gage talking about openFrameworks. And for nearly-entirely open source hardware, there’s a tantalizing-looking workshop combining Android with Arduino, too.

http://artandcode.ning.com/

There’s quite a lot more to say about this, but I hope this whets your appetite.

And, of course, riding the train to Pittsburgh or your nearest university or open source workshop, now you’ll have Thump which which to make some thumping tracks on your iPhone.

First up, here’s a demo of the new app FingerPlay MIDI, which turns Android into a simple touch controller. True, we’ve seen similar things on iPhone, and Apple’s platform has precise multitouch which Android lacks, but it’s nice to see the concept extended across platforms. Big thanks to postromantic on Twitter for the tip! (Follow cdmblogs for more.)

FingerPlay MIDI

I can’t tell yet if this will be open source – that would actually be nice, I think, as it’d allow the community of developers to have a shared set of tools. (In fact, it seems a logical model would be to cash in on general-market apps and open source the more music-specific, niche stuff.)

In other Android mobile news, Christopher Souvey continues to work on his Musical application and the Musical Pro desktop app. The desktop client works with MIDI over Wifi, and thanks to the Cupcake OS update, latency is greatly reduced after a complete rewrite and the creation of custom drawing and event handling and controls. Check out the slick new tuner and UI Christopher has been developing, too.

http://www.souvey.com/ [blog with all the latest]
http://www.souvey.com/musical/

This play-along piano is probably not something any of you folks desperately need, but it is a good demonstration of what’s possible.

Another interesting thread to follow will be the growing power of Web apps. On Android, you’re already able to combine a Web app with the Java APIs, and going another level, mobile apps with native ARM code for the processor. Translation: while phones still have a fraction of the power of your computer, it’s getting easier for developers to work across platforms and to take advantage of what power is there. That’s leading to trends that could be of use not only to a single platform (Android, iPhone), but to mobile devices in general.

Handmade Music hits Brooklyn again Thursday night with a terrific lineup:

• Robotic gamelan instruments with the Gamelatron, created by Zemi17 and the League of Electronic Musical Urban Robots (LEMUR) – check the video above!
• Rescued PDAs and iPods making music, with the Linux-powered ReWare project (which even allows you to run Pd on an old iPod), by Hans-Christoph Steiner – expect a box full of handhelds making noise
• Gestural Android handheld music, as I demonstrate the possibilities of the Google Android platform and G1 phone for OSC
• The Arduino-based Hard/Soft synth, designed by Gijs Gieskes and built by MAKE’s Collin Cunningham

Full project details at:

http://handmademusic.noisepages.com/

How to participate:

Online! Wherever you are in the world, you can join our live video stream:

http://www.ustream.tv/channel/cdm-tv

Apologies: while a test of the connection had worked for us last time, network performance was inexplicably poor. We’ll try to work on a better solution for the future. It’s the challenge of relying on a connection other than your own.

Schedule:

7:00p Online chat with the creators

7:30p Public event starts

8:00p Performances + demos

You can also ask questions to our creators by leaving them in comments here, or the day of / during the stream by sending a Twitter message with hashtag #cdmtv. (Follow CDM on Twitter) We’ll have clips of the show available by Friday

In NYC:

FREE, at Brooklyn’s 3rd Ward, 7:30p Thursday. rsvp@3rdward.com or on Facebook

Directions

3rd Ward

Thanks to Pabst Blue Ribbon for the free beer, plus our co-organizers at MAKE, Etsy, and XLR8R.

Last-minute NYC-area projects! If you have a project you want to bring, we will have a PA, amp, and projector. We welcome those last-minute projects that manage to come together. Just bring it by and find me at about 7p.

In Your Neighborhood:

We have folks interested in starting up Handmade Music around the US and internationally. Sign up via Google Docs if you have any interest in helping organize (no commitment) and expect information in the next couple of weeks.

Reware your PDA from Hans-Christoph Steiner on Vimeo.

Give a hoot – don’t pollute with your old mobile gear. Make musical creations with it instead, powered by Linux.

Sure, there are wonderful things happening with mobile music applications on platforms like the shiny, new iPhone. But remember how technology was supposed to democratize access? Lots of us don’t have the money for a new iPhone or iPod. And how many of us have outdated Pocket PCs and Palms collecting dust? How many of these highly toxic devices get thrown away?

Linux to the rescue.

One of the biggest hits of my talk at the OFFF Festival in Lisbon, Portugal was the mention of the Reware, a project by Hans-Christopher Steiner, who is doing research at New York’s Eyebeam. He has literally a box full of old PDAs – the kind a lot of people would give away at this point – which he has rescued in order to reuse as development platforms and musical devices.

There’s something just stunning about watching an old Pocket PC transformed into an interesting musical device. It’s like the feeling you get when you save a puppy with the help of a rescue / adoption agency, and instead of being put down, Buster turns out to be an agility champion. (Sorry. I really love dogs.)

Reware Project at Eyebeam

For a sample project, here you can dual-boot Linux on an old Palm:

Reware your PDA: dual boot Linux on a Palm TX from an SD card

Once you’ve done that, you can run your own creations and even Pd patches on your mobile. Even old iPods can work.

Pd Music Patching on PDAs

It’s a little trickier to recycle older embedded devices than it is desktop computers: for one thing, many of these devices lack floating-point calculation capability. (The FPU on the iPhone is one of the things that makes it so nice.) For fans of the multimedia environment Pd (Pure Data), the variant PDa (“Puredata anywhere”) is the solution. It rewrites signal processing as fixed point (integer) processing. It’s nowhere near as fast as a floating point-native Pd, and there are some other caveats, but there’s still a whole lot you can do with it. This is also good news for the currently-shipping Google Android handset, the HTC G1, which also lacks an FPU.

PDa 

Gunter Geiger is responsible for PDa, with help from lots of other folks. Now Hans is packaging all this stuff together to make it easier to run.

See it in Person; More Soon!

If you’re in the New York area, next week Hans is coming to Handmade Music to show off the work he’s doing. Check out the lineup on our new, evolving Handmade Music minisite:

http://handmademusic.noisepages.com/

That’s free, 7:30pm Thursday, May 21 in Brooklyn at 3rd Ward.

For fans of Android, I’ll be talking about development on Google’s own open source, Java-based mobile platform, which also runs the Linux kernel.

Android is itself getting ported to alternative platforms, again thanks to the magic of GNU/Linux and open source. Here’s just a small sampling:

Android Ports and Hacks Round-up

If Android also gives us native library access, it could become powerful for music. Even with just the 1.5 SDK, there’s a Java library for interactive music production. Both projects should cross-pollinate, though, because of the common Linux kernel between them.

If you’re not in the New York area, we’ll post details early next week about a live webstream. And we should have additional video after the event.

Hans and I are also working on getting Pd running on the BUG, which is both open-source software and hardware.

To round things out, here’s a video by Public Radio International’s Takeaway, showing how Hans is working with hackers doing other super-cool projects at Brooklyn’s NYC Resistor. It’s just one of many hacklabs sprouting all over the globe.

The “library access” in the 3.0 SDK is only a player control API similar to that of the iPod; there is not even read only file access for MP3s nor any way to modify the output from the library. So no iPhone DJing, no BPM detection, no interactive PD or Reaktor patches with your library.

Unfortunately, this seems consistent with Apple’s desire to be the one and only media player on the device. I’m hoping that this is still something Apple plans to add – imagine the ability to add effects or run games based on the library (a la the PC game Audiosurf) or create DJ apps. I know many people who use iPhone or iPod as sample players or backups for live sets; having a custom player app could also be useful.

By comparison, Google’s Android has no such limitations on its MediaPlayer class – the fundamental difference being that you aren’t limited from playing media on your device. Unfortunately, Android has its own limitations: no real audio buffer access, which means it’s not possible to build effects or DJ apps or games on Android, either.

And that’s typical of the sort of situation the newest mobile devices present. We have the iPhone, more sophisticated technically, but limited, apparently, by design in order to protect Apple control over certain functions. Then we have the Android, philosophically unlimited but technically limited by some key missing capabilities.

My question is, which device will evolve first to give us the freedom to make use of its full potential?

No file or output access to iPhone MP3 library – 3.0 SDK still too restrictive

If we’re lucky, perhaps the 3.1 SDK? (Or something we’ll still see in 3.0 that isn’t done yet?)

We’ve got further compelling evidence Apple doesn’t really own multi-touch and multi-touch gestures — and that other devices and interfaces will press forward (which is a good thing for everyone). Lest you think I’m straying too far from creating digital music, by the way, I think this means lots of new music apps – as musicians have devoured multi-touch more than any other group (and certainly have used it for the coolest stuff).

I am concerned about how multi-touch innovation will wrangle with over-zealous intellectual property legal wrangling. But hopefully I made it clear that, even with my concerns about Apple, the report that Google had pulled multi-touch capabilities to please Apple was full of question marks.

Luke Hutchison is more of an expert in this field than any Silicon Valley rumor reporter. Luke pulled off the kernel module hack that turns the Android G1 into a multi-touch gesture-capable device (with, incidentally, some examples that have tantalizing possibilities for musical applications). He has detailed instructions on that, if you’re interested – and his familiarity with the code gives him a compelling argument that Google did not cave to Apple – and Apple may not even have relevant patents in this case.

It’s worth reading his whole story as it’s full of technical details as far as multi-touch’s future on G1, but here’s the executive summary as far as Apple blocking multi-touch on Android:

(1) The G1 was simply never intended to be a multi-touch device.
(2) Apple’s multitouch patent may not even cover the pinch gesture.
(3) Google *is* interested in multitouch capabilities, it’s just nowhere near the top of their priority list.
(4) Google will deal with legal issues if and when they come up, but that hardly stops them doing something they think should be done.
(5) Apparently the driver for a resistive MT-capable/iPhone-like touchscreen was checked into the git kernel tree after the 1.0 release, so we now have (at least?) two MT-capable drivers in the tree.

In other words, if you make an iClone, expect to hear from Apple legal. If you just want to use or develop multi-touch devices and interfaces, rest easy – because even if Apple decides to make trouble, they’re likely facing even more multi-touch gesture-controlled devices and law teams to back them up.

Definitely worth reading, at Luke’s blog:
The Android Multi-Touch Conspiracy… and more tinfoil hats

Zoom-Zoom-Zoom — Get Multi-Touch Zooming Support on your T-Mobile G1 TODAY (and by the way, you can hack the kernel on new G1s without the Android developer unit?)

Apple’s iPhone should be a herald of a new age in interface design. But now, with speculation that Apple and Palm could get into a patent battle, and murky concerns about patents in multi-touch interface design in general, it’s unclear how much intellectual property legal wrangling will have to happen first.

I’m going to resist turning this into a long rant – partly because I think the jury is out on so many issues. It’s never been entirely clear what Apple continues sacred in its intellectual property on the iPhone. It’s even less clear – with similar multi-touch designs spreading back decades and murky law around gestures in general – what their legal standing is. No one knows at this point whether there will actually be a lawsuit between Palm and Apple (or which direction). But one thing I can say with confidence: we need alternatives to Apple. Even if you love your iPhone, I think you’ll agree it’d be tragic if other vendors didn’t push the technology forward. And we need alternatives like Google Android that support real open development, release free and open source code, and provide an option to Apple’s deeply proprietary, restrictive development platform. Innovative music software in particular won’t be able to thrive if alternatives are closed or nonexistent.

Here’s a quick look at where we’ve been, and where things are:

This has been a storm cloud since the beginning. Me, in January 2007, immediately following the keynote: Macworld: Will Apple Keep its iPhone Closed? Multi-Touch Patents? (I wish I had been wrong. No one believed me at the time that these two areas would be big issues.)

The original tech predates the iPhone. Engadget in 2007 on Apple’s multi-touch roots – FingerWorks gave them a patent portfolio and some key technology.

Google may have dropped out of the race. VentureBeat has a source that claims Google voluntarily dropped multi-touch to keep Apple happy. Even if that’s not true, I think potential legal battles with Apple – and the incorrect notion among consumers that this is Apple’s invention – could have a chilling effect. Update: There may indeed be some chilliness in the air, but there’s strong evidence that Google didn’t “cave” to Apple somehow — they just didn’t get around to it. And a multi-touch G1 may not be far off. Just asked the guy who’s already hacked the G1.

Both Apple and Palm are loaded up with patents – and no one knows what will happen. Engadget analyzes the potential for a Palm/Apple legal standoff – but there are two major issues here. One, Palm has a healthy patent portfolio of their own, meaning they could counter-sue. Two, no one knows if anything will come of this – aside from some saber rattling, we’re not even sure there will be a suit.

Just to keep things in perspective, though: I think multi-touch in general is safe. It’s a technology coming to phones, mobile devices, computers, Windows 7, Synaptic trackpads, Linux … the list goes on. To me, the question is whether developers will be free to try ideas without lawyers breathing down their necks, and that’s very much an open question.

And I think the deeper questions about whether open development, as on Android, can be competitive, may prove to be more important in the long run. Apple aside, we need more common-sense, modernized patent law – even if the Android in this case voluntarily dropped a feature, you can see that the issues are linked. And we need to have open development if people are to have freedom to experiment with design. This is about more than Palm and Apple; it’s about how we interact with our tech.