Let me introduce you to the “Whiny Little Bitch Contingent”. This was a term I coined in the late 2000′s to cover the Java developers who cried and moaned about the slow decline in Apple’s support for Java: the deprecation of the Cocoa-Java bridge, the long wait for Java 6 on Mac OS X, its absence from iOS, etc. Every time there was news on this front, they could be reliably counted on to dredge up Steve Jobs’ pledge at the JavaOne 2000 keynote to make the Mac the best Java programming environment… and to bring this up in seeming ignorance of the passage of many years, the changes in the tech world, the abject failure of Desktop Java, other companies’ broken promises (Sony’s pledge of Java on the PlayStation 2, the Java-based Phantom gaming console), etc.
The obvious trait of the Whiny Little Bitch Contingent is their sense of entitlement: companies like Apple owe us stuff. The more subtle trait is their ignorance of the basic principle that people, organizations, and companies largely operate in their own self-interest. Apple got interested in Java when it seemed like a promising way to write Mac apps (or, a promising way to get developers to write Mac apps). When that failed, they had understandably little interest in providing developers a means of writing apps for other platforms. I’m sure I’m not the only person to write a Java webapp on the Mac that I knew my employer would block Mac clients from actually using. By 2008, when Apple entered the mobile market with the iPhone, there was nothing about supporting Java that would appeal to Apple’s self-interest, outside of a small number of hardware sales to Java developers.
That’s what defines the WLBC to me: sense of entitlement, and an igorance of other parties’ self-interest (which leads to an expectation of charity and thus the sense of entitlement).
So, yesterday, Apple holds an event to roll out their whole big deal with Textbooks on the iPad. They look pretty, they’ve got an economic model that may make some sense for publishers (i.e., it may be in the publishers’ self-interest), etc. Also, there’s a tool for creating textbooks in Apple’s format.
And this is where the Whiny Little Bitch Contingent goes ape-shit. Because there’s a clause in the iBooks Author EULA that says if you’re going to charge for your books, you can only publish to Apple’s iBookstore.
So, let’s back up a second. The only point of this software is to feed Apple’s content chain. The only reason it is being offered, free, is to lure authors and publishers to use Apple’s stuff… which in turn sells more iPads and gives Apple a 30% cut. If you are not going to put stuff on Apple’s store, why do you even care about this? Hell, I don’t develop for Microsoft’s platforms, so if they see the need to turn Visual Studio into an adventure game… hey that’s their problem.
If you’re not authoring for Apple’s iBookstore, why do you even care what iBooks Author does, or what’s in its EULA?
In decrying the “cold cynicism” of Apple’s iBook EULA, Marshall Kirkpatrick writes:
It’s hard to wrap my brain around the cold cynicism of Apple’s releasing a new tool to democratize the publishing of eBooks today, only to include in the tool’s terms and conditions a prohibition against selling those books anywhere but through Apple’s own bookstore
“Democratize the publishing of eBooks”? Where the hell did he get that? Maybe he watched the video and fell for the grandiosity and puffery… I never actually watch these Apple dog-and-pony shows anymore, as following the Twitter discussion seems to give me the info I need. But thinking that Apple is in the business of democratizing anything is nuts: they’re in the business of selling stuff, and the only reason they’d give out a free tool is to get you to help them sell more of that stuff.
I didn’t download iBooks Author, even though you’d expect an Apple-skewing author like me to be one of the first onboard. Frankly, I’m pretty tired of writing, as the last two books have been difficult experiences, and the thought of starting another book, even with a 70% royalty instead of 5%, is not that appealing. A year ago I thought about self-publishing a book on AV Foundation, but right now I lack the will (also, I’ve failed to fall in love with AV Foundation, and blanch at its presumptions, limitations, and lack of extensibility… I much prefer the wild and wooly QuickTime or Core Audio).
So, if we’re going to talk about iBooks Author, let me know how it holds up for long documents: if it’s pretty on page 1, is it still usable when you’re 200 pages in? Does it offer useful tools for managing huge numbers of assets? Does it provide its own revision system and change tracking, or does it at least play nicely with Subversion and Git? Can it be used in a collaborative environment? These are interesting questions, at least to people who plan to use the tool to publish books on the iBookstore.
But if Apple’s not giving you a pretty, free tool you can use to write .mobi files that Amazon can sell Kindles with? Sorry, Whiny Little Bitch Contingent, I’ve got zero sympathy for you there. Call it a third party opportunity. Or just put on your big boy underwear and do it yourself.
Take it, Geddy:
You don’t get something for nothing
You can’t have freedom for free
You won’t get wise
With the sleep still in your eyes
No matter what your dreams might be
I make my living developing copyrighted content. I pay my Federal and Michigan taxes with the income I derive writing iPhone and iPad apps, and books about programming.
It is absurdly easy to pirate my work. Google for “adamson ios sdk torrent” and you’ll find the latest book I’m co-authoring available by BitTorrent, despite the fact that my co-author and I haven’t even finished the book yet. Jailbreaking of the iPhone also makes it easy to steal the apps I write.
Nevertheless, I am appalled by the proposed “Stop Online Piracy Act” (SOPA), and the manner in which it has been brought before Congress. The December hearings in the House featured effectively no competent techincal testimony from Internet engineers, and looked to me like it was meant for show at best.
The legislation is rife with over-broad language and unintended consequences, and has little prospect of effectively stopping piracy, while causing massive collateral damage to all manner of legitimate and productive business and art.
Its supporters in Hollywood claim they’re protecting jobs, but what they’re protecting, at best, are their own outdated business models of deliberate scarcity. If you want to reform IP law to protect jobs, how about cleaning up the granting of software patents for trivial ideas, something that presents an imminent mortal threat to my industry?
This is terrible, terrible legislation, and it is shameful that the Congress has allowed it to get as far as it has. If it passes, you will be held accountable.
Your constituent,
Chris Adamson
There’s nothing like losing your editor — to Apple, no less — to ratchet up the heat to finish a book that has been too long on the burner. But with Chuck doing exactly that at the end of December, Kevin and I had the motivation to push aside our clients and other commitments long enough to finally finish the Learning Core Audio book (yes, the title is new), and send it off to the production process.
In our final push, we went through the tech review comments and reported errata — Lion broke a lot of our example code — and ended up rewriting every example in the book as Xcode 4 projects, moving the base SDK to Snow Leopard, which allowed us to ditch all the old Component Manager dependencies. For the iOS chapter, we rev’ed up to iOS 4 as a baseline and tested against iOS 5.
One of the advantages of Xcode 4 is that the source directory is cleaner for source control (no more ever-changing build folder that you have to avoid committing), while also offering a pretty simple way to get to the “derived data” folder with the build result, which was important for us because we have a number of command-line examples that create audio files relative to the executable, and Xcode 4 makes them easy to find.
In our final push, we also managed to get in an exercise with the AUSampler, the MIDI instrument that pitch-shifts the audio file of your choice, into the wrap-up chapter. So that should keep things nice and fresh. Thanks to Apple for finally providing public guidance on how to get the .aupreset file to load into the audio unit, and how the unit deals with absolute paths to the sample audio in the app bundle case.
Updated code is available from my Dropbox: learning-core-audio-xcode4-projects-jan-03-2012.zip
From here, Pearson will take a few months to layout the book, run it by us for proofing and fixes, and send it off to the printer. So… paper copies probably sometime in Spring. The whole book — minus this last round of corrections — is already on Safari Books Online, and will be updated as it goes through Pearson’s production process.
It seems like there’s been a big uptake in Core Audio in the last year or two. More importantly, we’ve moved from people struggling through the basics of Audio Queues for simple file playback (back in iPhone OS 2.0 when Core Audio was the only game in town for media) and now we see a lot of questions about pushing into interesting uses of mixing, effects, digital signal processing, etc. Enough people have gotten sufficiently unblocked that there’s neat stuff going on in this area, and we’re fortunate to be part of it.
The Prags started a forum for readers to discuss their thoughts about Steve Jobs, following his death yesterday, and asked some of their writers to prime the pump with some initial posts.
Mine, A Moral Code Cast in Steel, takes its inspiration from a quote from Ayn Rand’s Atlas Shrugged, about the expression of human genius and creativity in the form of physical things, the things we create.
It’s a dicey book to be quoting because there are a lot of people who hate, absolutely hate, Ayn Rand, and to co-opt a dead person and attach them to the selling of a product or belief system is potentially tasteless and offensive (yes, irony, thanks for noticing). And some of the objectivists doing so are being pretty ham-handed about it. The only reason I thought it was OK to proceed with is because we have that interview of Steve Wozniak saying that Jobs was inspired by Atlas Shrugged in his youth. That’s a sterling source, and easily verifiable, and that made the Jobs-Atlas analogy a viable and fair angle to take.
Plus, I think the central points really hold: that the will and ingenuity of the creator can be perceived in his or her works (indeed, it is what separates them from being raw materials), and that Jobs was particularly fascinating in finding inspiration and truth from many different sources: East and West, spiritual and physical, technology and liberal arts.
Of course, one can’t help but bring one’s own beliefs to the table. Here’s the scene immediately to my left while I work (click for full-size):
Anyways, Bill got on board back in the NeXT days, and he’s got a great post too, so be sure to check that out.
Yuna:book cadamson$ svn commit
Sending book/ch11/Ch11.txt
Sending book/ch12/Ch12.txt
Transmitting file data ..
Committed revision 237.
Yuna:book cadamson$ Folks, that’s the svn commit that marks the completion of the first draft of Core Audio.
How long has it taken to get here? Subversion’s got that too:
Yuna:coreaudiobook cadamson$ svn log -r1 .
----------------------------------------------------
r1 | invalidname | 2010-01-06 17:18:06 -0500 (Wed, 06 Jan 2010) | 2 lines
Created the usual trunk, tags, branches.
----------------------------------------------------Yeah, almost two years from when I took over after original author-fade… probably will actually be two years by the time we handle rewrites and comments from reviewers, Lion fixes (AudioComponentInstance instead of ComponentInstance, etc.), and get through the production process of copy-edit, layout, and printing.
Oh, and will you be getting your money’s worth?
Yuna:book cadamson$ wc ch??/Ch??.txt
208 3972 24817 ch01/ch01.txt
295 5440 32883 ch02/Ch02.txt
371 5344 34641 ch03/Ch03.txt
623 6674 44278 ch04/Ch04.txt
318 4052 26261 ch05/Ch05.txt
515 5161 37540 ch06/Ch06.txt
884 10837 72025 ch07/Ch07.txt
740 9156 60837 ch08/Ch08.txt
738 8070 54086 ch09/Ch09.txt
910 9949 68737 ch10/Ch10.txt
498 6233 40981 ch11/Ch11.txt
77 2080 12570 ch12/Ch12.txt
6177 76968 509656 total
Yuna:book cadamson$ At a standard estimate of 250 words per page, this 80,000-word book should clock in around 320 pages. We have a few figures, so maybe it’ll be more like 350. We’ll see. Enough to cover what we thought was crucial, not so big that it could stop a charging bison.
More to do, but nice to have finally reached this milestone. Thanks to everyone who’s waited so patiently for it.
I hopped in on the MIDI chapter of the nearly-finished Core Audio book because what we’ve got now is a little obscure, and really needs to address the most obvious questions, like “how do I hook up my MIDI hardware and work with it in code?” I haven’t taken MIDI really seriously in the past, so this was a good chance to catch up.
To keep our focus on iOS for this blog, let’s talk about MIDI support in iOS. iOS 4.2 added CoreMIDI, which is responsible for connecting to MIDI devices via physical cables (through the dock connector) or wifi (on OSX… don’t know if it works on iOS).
Actually getting the connection to work can be touchy. Start with the Camera Connection Kit‘s USB connector. While Apple reps are typically quick to tell you that this is not a general-purpose USB adapter, it’s well-known to support USB-to-MIDI adapters, something officially blessed (with slides!) in Session 411 (“Music in iOS and Lion”) at WWDC 2011.
The catch is that the iPad supplies a tiny amount of power out the dock connector, not necessarily enough to power a given adapter. iOS MIDI keeps an updated list of known-good and known-bad adapters. Price is not a good guide here: a $60 cable from Best Buy didn’t work for me, but the $5 HDE cable works like a charm. The key really is power draw: powered USB devices shouldn’t need to draw from the iPad and will tend to work, while stand-alone cables will work if and only if they eschew pretty lights and other fancy power-draws. The other factor to consider is drivers: iOS doesn’t have them, so compatible devices need to be “USB MIDI Class”, meaning they need to follow the USB spec for driver-less MIDI devices. Again, the iOS MIDI Devices List linked above is going to help you out.
For keys, I used the Rock Band 3 keyboard, half off at Best Buy as they clear out their music game inventory (man, I need to get Wii drums cheap before they become collector’s items). This is
Once you’ve got device, cable, and camera connection kit, try playing your keys in GarageBand to make sure everything works.
If things are cool, let’s turn our attention to the Core MIDI API. There’s not a ton of sample code for it, but if you’ve installed Xcode enough times, you likely have Examples/CoreAudio/MIDI/SampleTools/Echo.cpp, which has a simple example of discovering connected MIDI devices. That’s where I started for my example (zip at the bottom of this blog).
You set up a MIDI session with MIDIClientCreate(), and make your app an input device with MIDIInputPortCreate(). Both of these offer callback functions that you set up with a function pointer and a user-info / context that is passed back to your function in the callbacks. You can, of course, provide an Obj-C object for this, though those of you in NDA-land working with iOS 5 and ARC will have extra work to do (the term __bridge void* should not be unfamiliar to you at this point). The first callback will let you know when devices connect, disconnect, or change, while the second delivers the MIDI packets themselves.
You can then discover the number of MIDI sources with MIDIGetNumberOfSources(), get them as MIDIEndpointRef‘s with MIDIGetSource(), and connect to them with MIDIPortConnectSource(). This connects your input port (from the previous graf) to the MIDI endpoint, meaning the callback function specified for the input port will get called with packets from the device.
MIDIPackets are tiny things. The struct only includes a time-stamp, length, and byte array of data. The semantics fall outside of CoreMIDI’s responsibilities; they’re summarized in the MIDI Messages spec. For basic channel voice messages, data is 2 or 3 bytes long. The first byte, “status”, has a high nybble with the command, and a low nybble indicating which MIDI channel (0-16) sent the event. The remaining bytes depend on the status and the length. For my example, I’m interested in the NOTE-ON message (status 0x9n, where n is the channel). For this message, the next two bytes are called “data 1″ and “data 2″ and represent the rest of the message. The bottom 7 bits of data 1 identify the note as a number (the high bit is always 0), while the bottom 7 bits of data 2 represent velocity, i.e., how hard the key was hit.
So, a suitable callback that only cares about NOTE-ON might look like this:
static void MyMIDIReadProc (const MIDIPacketList *pktlist,
void *refCon,
void *connRefCon)
{
MIDIPacket *packet = (MIDIPacket *)pktlist->packet;
Byte midiCommand = packet->data[0] >> 4;
// is it a note-on
if (midiCommand == 0x09) {
Byte note = packet->data[1] & 0x7F;
Byte veolocity = packet->data[2] & 0x7F;
// do stuff now...
So what do we do with the data we parse from MIDI packets? There’s nothing in Core MIDI that actually generates sounds. On OSX, we can use instrument units (kAudioUnitType_MusicDevice), which are audio units that generate synthesized sounds in response to MIDI commands. You put the units in an AUGraph and customize them as you see fit (maybe pairing them with effect units downstream), then send commands to the instrument units via the Music Device API, which provides functions like MusicDeviceMIDICommand, and takes the unit, and the status, data1 and data2 bytes from the MIDI packet, along with a timing parameter. Music Device isn’t actually in Xcode’s documentation, but there are adequate documentation comments in MusicDevice.h. On OSX, the PlaySoftMIDI example shows how to play notes in code, so it’d be straight-forward to combine this with CoreMIDI and play through from MIDI device to MIDI instrument: get the NOTE-ON events and send them to the instrument unit of your choice.
On iOS, we don’t currently have instrument units, so we need to do something else with the incoming MIDI events. What I decided to do for my example was to just call System Sounds with various iLife sound effects (which should be at the same location on everyone’s Macs, so the paths in the project are absolute). The example uses 4 of these, starting at middle C (MIDI note 60) and going up by half-steps.
To run the example, you’ll actually have to run it twice: first to put the app on your iPad, then stop, plug in your keyboard, and run again. It might just be easier to watch this demo:
Anyways, that’s a brief intro to CoreMIDI on iOS. The book will probably skew a little more OSX, simply because there’s more stuff to play with, but we’ll make sure both are covered. I’m also going to be getting into this stuff at CocoaHeads Ann Arbor on Thursday night.
- Sample code:CoreMidiToSystemSoundExample.zip
