First revealed last month, PreenFM is an open source hardware synth. As the name implies, it’s an FM synth, with some very serious specs: up to six-operator FM synthesis with some nine algorithms, up to 4-voice polyphony (depending on algorithm), glide, selectable LFOs, modulation matrix, and preset banks with SysEx support. It’s all usable via a display and MIDI support.

It’s also fully open source hardware; whereas early efforts often had commercial restrictions attached, PreenFM is free for use under the GPLv3 and Creative Commons. And it’s got a unique platform under the hood: the open source LeafLabs 32-bit development platform gives this some serious horsepower. It’s very much in contrast to the ultra-inexpensive 8-bit brain of our own MeeBlip synth; think of the MeeBlip as an exercise in what you can do with a little two-stroke engine versus the V8 muscle in this. (The creator says the MeeBlip helped inspire his creation – yes, synths are multiplying!)

You may have glimpsed the PreenFM making the rounds online, but I got creator Xavier Hosxe to tell us more of the gory details and share some sounds.

CDM: So this is all based on the Leaf platform?

Xavier: Yes it’s built around a LeafLab board.
I coded a first version on the Maple [development board]; then when they announced their “Maple Mini,” I realized it was going to be very easy to plug it into a PCB.
I’m not directly connected to [LeafLabs]; I participated in the forum and learnt many things from the team.

They are very friendly and helpful.

What was it like working with the Leaf?

The LeafLabs boards uses an ARM Cortex-M3 microcontroller.

It’s a 32-bit chip runing at 72Mhz that can do 32-bit multiplication in 1 clock cycle, has 128Kb of flash [memory] and 20Kb of RAM. That seems very few but it’s not, PreenFM software uses 92Kb for the moment.

LeafLabs provide a Linux/gcc toolchain that allows to develop in your IDE of choice… Eclipse in my case, which is very confortable.

They also provide a strong bootloader and some libraries that worked perferfeclty for my needs : Usart (Midi), I2C (EEPROM), LiquidCrystal (LCD).

What will you get in the PreenFM kit?

All you need to build yourself a complete synth: PCB, screws, resistors, ICs, audio/midi jack, box, 20×4 LCD, encoders, knobs, buttons… even an USB cable [for power].

You’ll also get a Maple Mini board with PreenFM soft preloaded. The Maple Mini is easily updatable, and you can experiment lots of different things with it.

PreenFM C++ source code is available on GitHub. It’s easy to read and modifiable. If you want to see your name to welcome you on the boot screen, go ahead

To build the kit, you only need a soldering iron and some solder.

There will be 2 differences with the photos you can see on the site: the final PCB will be blue (I should receive them next week). [Ed.: See the photo in blue at top; the orange one is included here for variety! -PK]

Xavier also sends along some welcome news:

Here is a sound I can get with my soon-to-be-released StepSequencer feature in PreenFM.

This is a single voice of a simple 3-oscillator voice. 1 very slow LFO + 2 * step sequencer routed to the modulation indices.

PreenFMStepSeq by cdm

Here’s a sound sample:
PreenFM 1 by cdm

http://www.preenfm.net

The generation of people who defined modern computing seems to be passing this year. Following Max Mathews, another Bell Labs titan is lost to us: Dennis Ritchie is the man who created the original C programming language (again at Bell Labs) as well as co-developed the UNIX operating system. President Obama commented that many people learned of Steve Jobs’ death on a device “he invented.” For all Jobs’ contributions, it is as untrue to say that as it is true to say the same of Ritchie: you are quite literally reading this story as served by software derived from his creations on UNIX, using tools written primarily in the language he, with others, devised.

For music, C endures in some form as the basis of the vast majority of tools we use for musical computation – that is, his creation is at the heart of the software with which we all make music. And just as Mathews made the computer sing for the first time, C is a lingua franca on which musical expression is based, the kernel of the vast array of sounds computers today make.

But C is important not simply because, in some form, it remains at the heart of much of the computer code written today. It also introduced in a material sense the idea of portability and cross-platform code, allowing in turn music tools like Csound and others to appear on new computers rather than pass away. It formalized coding concepts that, even in radically-different, more “modern” languages survive. That means that for people expressing musical ideas in code – and anyone using the software that results – software is not tied to specific hardware, lost as new generations of gear cause the old to pass away. The ideas behind C allow computer music to pass from one generation to another – to outlive us.

Ritchie would probably at this point hasten to add that he didn’t work alone, that his work was based on others, that he had colleagues like Ken Thompson who worked with him on C and UNIX. Such is the nature of invention, and unlike the titanic egos of the past (yes, Henry Ford and Thomas Edison, we’re looking at you), some of today’s creations were built by people whose impact was no smaller, but who have been far humbler and lesser-known.

So, get to know Dennis and the many colleagues who survive him. Marvel that the “machine” is not some alien robot at all, but that in your hands, you hold the contributions of creative human beings, the thoughts of complete strangers encapsulated in front of you, and that at the end of the day, you can make it all sing a song.

Via TechCrunch

This update I believe is worth a second post, as it makes visible the otherwise-mysterious algorithms producing music in our previous post.

And yes, I believe this is “music,” naysayers aside. Whether it’s good music is in the ears of the listener, but if you can describe this much sound with this little code, imagine what’s really possible in computer music. Whatever it is you want to hear, it’s within the power of your imagination to describe it, on a score or in code, either one.

Thanks to none other than Stephan Schmitt for the tip.

You know you’re in for something different with an article that contains this line: “as 256 bytes is becoming the new 4K, there has been ever more need to play decent music in the 256-byte size class. ”

In just a single line of code, Finnish artist and coder countercomplex, working with other contributors, is creating “bitwise creations in a pre-apocalyptic world.” What’s stunning is to listen to the results, even if you have trouble following the code – the results are complex and organic, glitchy but with compositional direction, as though the machine itself had learned to compose in its own, strange language.

This is, naturally, the opposite of the musical coding in the previous post: in place of human-readable languages representing abstractions atop other abstractions, this is pure algorithm transformed into music. Geeky, yes, but it also says something about musical composition and thought independent of the computer. It is as compact an expression of a human musical idea as one could imagine.

I recommend reading the whole blog post (and following the blog for new developments). Embedded in this whole exercise are thoughts about musical algorithms, the history of chip and 8-bit music and the demoscene, and, most interestingly, the question of whether digital music might yet yield “new” (or at least largely unknown) discoveries:

Hasn’t this been done before?

We’ve had the technology for all this for decades. People have been building musical circuits that operate on digital logic, creating short pieces of software that output music, experimenting with chaotic audiovisual programs and trying out various algorithms for musical composition. Mathematical theory of music has a history of over two millennia. Based on this, I find it quite mind-boggling that I have never before encountered anything similar to our discoveries despite my very long interest in computing and algorithmic sound synthesis. I’ve made some Google Scholar searches for related papers but haven’t find anything. Still, I’m quite sure that at many individuals have come up with these formulas before, but, for some reason, their discoveries remained in obscurity.

Algorithmic symphonies from one line of code — how and why? [countercomplex]

But can you dance to it?

Matt Ganucheau contributed to this story from San Francisco.

You may have already seen FaceOSC, free software that eases the use of facial tracking from a computer camera for use as a controller, here with music software (top). Synthtopia picked up the story in July, featuring artist and engineer Kyle McDonald. But one FreeKa Tet has done his own implementation (second from top), and while the video is a bit grainy, he sounds wonderfully terrifying, as if his face is trying to slip out of The Matrix.

Sometimes, I’m rendered entirely silent (no, really, it happens), and it’s best to let videos speak for themselves. So here, after the jump, are some whimsical and wild prosthetic sound light-up … hell, I don’t have any idea what’s going on, but I’m enjoying it.

I dare you to start some conversation about musicality. Just don’t be surprised, comment trolls, if you find yourself abducted by a glowing and oddly glitchy-sounding creature with long, monstrous fingers. I’d watch what I say, frankly. Remember the old saying “on the Internet, no one knows if you’re a dog?” I expect that extends to space aliens, too.

Plenty more where those came from.

Oh, look, I could have done my research and seen there’s a bio for Mr. FreeKa Tet, aka Bacon ClapCLAP.
:

Extreme violent bursts, silence, speech, hard rock samples, strange atmospheres, Burgers , American Idol Icon, crackles, retardation, puking static, rocking a gabber party, cutting a worm in half and watching both parts moving, get a watch tatoo on his wrist, confusing videogames with music, drawing little puke characters on friends faces …

Right. Okay. That cleared everything up.

Enjoy your weekend, folks, and stay high and dry, those of you here on the Eastern seaboard of the US.

I think the first time I really understood handheld music making was when I first tried Nanoloop on Game Boy. While the more-popular LSDJ tracker is powerful, Nanoloop’s interface was unlike anything I’d seen before: aggressively minimal, it embodies in its interface design the feeling of a blank sheet of paper. Adding an idea feels like composition, like genuinely exploring open-ended possibilities and discovering what melodies may result. Now, Nanoloop – already on iOS – is available for Android, too.

It remains simple stuff, the sense of what a music maker looks like when designed for your hand rather than translated to mobile from desktop, studio-style workstations. There are six fixed channels, each assignable to a synth (FM, noise, or filtered wave) or a sampler. Then, each channel takes eight patterns. There’s a step sequencer, the ability to resample, and song editor with loops. The sampling capabilities are especially nice on Android, as you can now sample from the mic or load samples right onto the SD card. (The mic you can use on iOS, but not the SD card, of course.) You can export OGG files to your library, turning your Android device into a DJ-set-ready pocket music library, or send and receive projects via email. Via iTunes, you can even exchange files with the iPhone version, in case you have an Android phone and an iPod touch or some similar arrangement.

This isn’t a port of the Game Boy nanoloop, developer Oliver Wittchow is quick to note. It’s not for chip music, or emulating game consoles. It’s for … well, Android music. But make no mistake: while the tool feels fresh and native to the new platform, it also carries the spirit of the Game Boy version. And that spirit is handheld music making, not just the aesthetics of the chip, but the feeling of using a minimal device scaled to your hands, something you can use on the go.

Oliver tells CDM that he has used a lot of native code (via the NDK), as he did non-object-oriented C (not Objective-C) in the iOS version. He says it’s about 1:1 C and Java: “I could use the iOS code almost unmodified and get the sound engine and touch input to work immediately. I had an almost fully working nanoloop within few days – without any graphics though.
Now I ‘just’ had to write Java code for GUI, file access, recording functions and the different menu structure.”

The results, he says, are a little strange if you’re looking at the code (lots of getters and setters, C mixed with Java), but it works well.

Android owners, I’d love to hear how this works on your device. Let us know – just be sure to fill out a bug report. As the Market page notes:

Nanoloop works on a variety of devices, including HTC Desire, Motorola Droid and also midrange phones such as HTC Legend and XPERIA X10 mini. However, this is the first release and of course it has not been tested on all Android devices yet. If you experience crashes or other problems, please report them via e-mail or the anonymous bug report form at www.nanoloop.com. Thank you.

Now if we can just have some luck with Bluetooth MIDI at our hacklab tomorrow, this could be another candidate.

Oh, and most of all, I’d love to hear the music you make.

nanoloop on the Android Market (a stunning EUR1 … that’s a no-brainer. Better than an espresso shot!)

nanoloop.de [iOS, Android]

See our previous Android music round-up

For the historical record, here’s nanoloop for Game Boy on CDM – from 2004. It’s actually come quite a ways since that release, but the spirit is the same.
http://createdigitalmusic.com/2004/11/updated-nanoloop-20-game-boy-instrument/

Ben X Tan writes to let us know he’s working with hacks for Microsoft’s Kinect 3D camera system for Xbox to perform MIDI control. Result: depth-sensing, gestural musical manipulations! It’s just a prototype, but since today I cover the larger landscape of what’s happening with Kinect, it’s well worth teasing. From the description:

Coded in C#.net using this: http://codelaboratories.com/nui

Very hacky ugly, yucky, alpha prototype, source code available here:
http://benxtan.com/temp/pmidickinect.zip

Next project is making a version of pmidic that uses Kinect. Then, you can control Ableton Live or any other MIDI software or hardware with you limbs. Isn’t that amazing!!!

If you are interested, you should also check out:
http://pmidic.sourceforge.net/
http://benxtan.com

He tells me, “It’s just proof of concept for now, but want to make something nicer in the long run The community on IRC for this stuff is great. Very supportive. I love all the hacking going on at the moment. Especially after watching the Social Network. Very inspiring!”

So, what’s this whole Kinect thing about, why should you care, why might it be useful to artists and musicians and designers generally, and where do you go to find the code? I’ve rounded up various hackers working on the project to answer those questions on Create Digital Motion (in this case, Capture Digital Motion):
Kinect Hacking and Art Round Table: Why it Matters, What You Need to Know

What if you could make any device or any software a re-programmable musical instrument, effect, or soundmaker? Your phone could be a touch-controlled effect, your tablet a sketchpad for interactive drum sequencers. Patches assembled on your desk on a computer could be taken with you in your pocket. And what if you could do all of this for free, using a time-tested environment?

libpd, authored by Peter Brinkmann, takes on that vision. It’s a way of making Pure Data (Pd), the visual development tool for interactive music and media, more accessible across a range of applications and gadgets. It lets you embed Pd pretty much anywhere. It’s not a new version of Pd. Instead, it makes use of the standard, “vanilla” distribution of the free and open source software. What’s different is that it separates the sound processing part of Pd from the part that talks to audio hardware, allowing Pd to run on a greater variety of mobile devices and inside other applications.

libpd:

• turns Pd into an audio synthesis and processing library
• liberates Pd from GUI and drivers
• allows for easy communication between Pd and the code into which it is embedded (so you can send and receive messages with your Pd patch)

Today, a team of developers and testers (including myself) is releasing the first version of libpd. It’s free to use on any device you wish, and free to modify. Because of its licensing, you can even build commercial applications with it. (That is, yes, it’s open source – but yes, it can also be useful if you’re a commercial developer. You don’t have to choose.)

http://gitorious.org/pdlib | community discussion

We’re just pleased to have a tool that makes experimenting with sound and music quicker, easier, and more flexible and compatible. It’s more fun that way.

Supported Platforms, What You Can Make

Right now, today, you can use libpd with:

Android: Thanks to Google’s NDK (Native Development Kit), you can use libpd with any Android device running OS 1.6 or later. Note that devices without the Google Market are often non-standard in other respects, so your mileage may vary, but we’ve found a wide variety of devices work quite well, including the Motorola Droid and Droid X, HTC Legend, and Google NexusOne.

iOS: iPhone and iPad models with the latest, armv7 processors work (3GS, iPad); we’re working to extend compatibility across more devices. Working with Peter Brinkmann, the RjDj development team contributed (and continues to contribute) free code that’s making iOS support compatible and high-performance. But the Objective-C classes mirror the Android and Java classes, meaning the two will stay in sync, and once you’ve learned one, the other will be a piece of cake. (Or coffee. Or cocoa. Or whatever.)

In each case, you just need libpd, Pd for making your patches (graphically), and a copy of the SDK for each mobile platform you want to use.

Additionally, you will soon be able make user interfaces for libpd using cross-platform HTML5, via Chris McCormick’s project WebKitPd. (It’s not quite ready for consumption yet, but will also be free and open source.) Android was the impetus and initial test platform for libpd, so right now it’s the most mature. But we hope to improve iOS compatibility and testing next.

Some Sample Apps to Try for Android

libpd is really aimed at developers who want to embed Pure Data into mobile devices, games, and so on, and soon also people working with Processing, Open Frameworks, and the like.

But if you’re eager to try this out as an end user, there are a number of packages you can try. They don’t show off everything libpd and Pd can do, but they do allow you to load up something on your device and make some noise.

Download the test packages from the libpd site:
http://gitorious.org/pdlib/pages/Packages

It includes a scene player for RjDj (see below).

Among the code included in the repository is one complete app, Peter Brinkmann’s own Circle of Fifths. He tells us:

Circle of Fifths: I wanted a circle of fifths tool for the subway, with exactly this kind of GUI. It also nicely illustrates the newly possible separation of concerns — Pd only does DSP, and an elaborate GUI is built somewhere else. It’s a demo and not optimized for universal consumption. In particular, it’s a bit CPU hungry because it’s actually simulating six Karplus-Strong strings in real time.

Of course, if string simulation is what you want to do, this also illustrates that you can – even on a phone.

Chris McCormick has created two libpd-based apps, one of which I feature in the video above. Can of Beats also makes use of WebKit as its UI rendering engine. Chris describes what he’s made:

Can of Beats: This is a procedural hiphop beat generator. The beats are generated using simple hand-crafted probability weightings for each type of sound at each position in the beat. In the Android app, you can also input simple melodies or basslines to go along with the beats.
http://mccormick.cx/projects/CanOfBeats/

Garage Acid Lab: This is an algorithmic, 303-style acid bassline generator. The app will make you an infinite number of different acid bass lines and garage style beats. You can also have some fun with the cutoff filter and delay unit settings with a kaos-pad style input. I want to work on this app a bit more to provide an ‘advanced’ mode which will let you write custom basslines, beats, and have more control over the effects. http://mccormick.cx/projects/GarageAcidLab/

RjDj, RjDj team. If you don’t know it by now, RjDj is a fantastic application built on Pd that makes interactive musical and sonic experiences deliverable in the same way as a digital album, not only to musicians, but anyone who wants to experience music and sound in new ways. libpd makes use of code contributed by RjDj. Future development on RjDj will use libpd. (More on those libpd-based versions, and the evolution of RjDj and RjDj Voyager, soon.)
http://www.rjdj.me/

Where to Get It, Where to Get Involved

1. Get the library. To get started, download libpd from its Gitorious source repository:
http://gitorious.org/pdlib

You’ll need Pd, too, if you don’t have it; vanilla Pd builds are available from the official Pd download page.

2. Join the community. You can discuss patching for libpd, developing using Pd, and making instruments and effects and other sonic creations for gadgets everywhere on our new community group:
http://noisepages.com/groups/pd-everywhere/

That will be a location specifically dedicated to the unique challenges of working with mobile gadgets; of course, see also the other great community resources for Pd.

Who made this: libpd was conceived by a team including Peter Brinkmann, Hans-Christoph Steiner, and myself, with input from the RjDj team (particulary Martin Roth). It was primarily developed by Peter Brinkmann, who applied his talents and the work he has done in JJACK, a Java API for JACK, with additional contributions and testing by our team and by Chris McCormick. Major thanks to Martin Roth and the folks at RjDj, to Miller Puckette (creator of Pd), and the generous attendees of our first hackday at the NYC Patching Circle, along with others who are testing now.

Tutorial Next Week; Your Feedback Wanted

I’ve been preparing a tutorial for working with libpd Android (initially), to be followed eventually for developing on iOS devices once we have a better handle on making that go smoothly. We’ll have a complete tutorial for you by next week. Processing is then my next priority.

An FAQ will also be available by then. That means, first, ask some questions!

Got specific questions about what this is for? How to get started? What you’d like to see in the tutorial? Ask away.

And please do get the discussion going not only here in comments, but in the Pd Everywhere group. (Noisepages registration is now open; if you have any trouble, let me know and I’ll sort you out.)

Party like it’s 1991 – your browser’s invited. A full-blown music production tool has been directly ported from the desktop to the browser using Flash, modeled with a tracker-style interface for fast, precise music editing. (In fact, a tracker, thanks to speedy entry from a QWERTY keyboard, seems to me an ideal interface for browser music. Trust me – it looks arcane at first, but trackers can be extremely friendly music interfaces. Just be prepared to look like a total geek once you’ve worked it out, because it’ll look even more arcane to everyone else)

The resulting tool comes with all the modules you’ll need, and it’s completely free to use. There’s even an included sample library.

Now, the next time you’re stuck in an Internet cafe, you can compose a song.

Creator Ruben Ramos says this is the first tracker on the Web, and shares his development process with us:

The sourcecode of the application is the same than the desktop version, it’s C++. I used a research project from Adobe Labs to build my sources for the AVM2 (ActionScript Virtual Machine 2), which is the last virtual machine used in Flash. This way, I got a binary version as a .swf of my original desktop-based application.

I wrote some parts code for this version, but only a few. For example the graphic rendering: in the desktop version was using the graphic card acceleration; for this version I implemented a software renderer.

After it, I added some special features for this version. For example, I implemented a filesystem with remote access to allow the load of resources stored on the server. With this feature songs and samples can be loaded from the webserver, which is good to have a base sample library available on the server.

Try it out for yourself:
http://www.skale.org/

Pictured: Looks native, but this app is built with a cross-platform library. And really, for music making – or great, immersive development, in general – does it matter?

The iPad has inflamed plenty of passions online. On this site, I’ve gotten a little flak from iPad lovers and haters alike. It goes something like this: “wait a minute, you’ve got all these criticisms of the iPad’s restrictiveness, but then you’ve got all these amazing music apps.” Or, on the other side: “why do you keep covering all these iPad music apps?”

In a word, yes. They’re not the same issue. I’ve talked to plenty of developers. The business draw on iPad is a big deal for independent, creative developers, so to the extent that Apple strategy makes the store a good place to sell apps, there’s some overlap. But the iPad has also been attracting plenty of music developers because of the quality of the APIs – developers who often aren’t pleased with the restrictions. Does the person who writes the audio drivers and APIs have anything to do with the lawyer who writes the developer agreement? Of course not.

The problem is, just as iPad/iPhone critics sometimes conflate issues in their rush to criticize the platform, some of the defense from the Mac community is getting a bit carried away, too. We’ve seen this with design issues, not just ideological or business issues: you go from “touch can be an expressive way to interact with a computer” to “throw out your QWERTY keyboards! They’re dead!” or “you’ll never read a magazine again” or “multitasking was a terrible idea in the first place.”

In this case, Apple made a fairly specific change to a developer document. That resulted in some criticism that was over the top (namely, people claimed it’d stop specific developer tools before they had verified whether that was actually the case). But it also resulted in some Apple apologism that was downright surreal:

All cross-platform development is bad? Wait – what?

And for that matter, is the mark of great software design now exclusively using Apple’s developer toolkits? Wouldn’t we sort of hope that, beyond those slick Apple UI widgets, someone somewhere might be developing the UI of the future? For that matter, do people not realize that a lot of what makes Apple’s quality exceptional is stuff you can’t see – things like multitouch firmware, high-quality audio drivers, and other fit-and-finish on the plumbing?

So, I invite you, dear reader, travel with me. I think we may actually have something on which iPad critics and fans alike can agree. It’s relevant to music, because music apps (along with games, incidentally) are the ones that are most intimate with this issue. And I suspect a lot of you use cross-platform tools to develop code for your day job.

The Catalyst: Apple’s Legal Change

Apple surprised many in the tech world last week by making a change – mandatory to all developers – that requires that applications for iPhone “must be originally written in Objective-C, C, C++ or JavaScript [running in the WebKit browser engine].” More specifically-worded, “Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited.” Because of the timing, and because of the further clarification, conventional wisdom suggests this is aimed at Adobe CS5′s tool for making native iPhone apps from Flash code. I don’t think it should be any surprise that that would get developers upset, not only those who use Flash, but even some loyal developers who don’t like being told what to do by Apple. (And I know at least some fairly big fans of the iPad weren’t fans of this change.)

Had it not coincided with Adobe working on CS5, I don’t know that this would have been big news; Apple already restricts the languages used to develop on their device. But I think what set people off may have been that very problem: people don’t know what it means, and that (rightfully) makes them nervous. While online debates have devolved into idealogical extremes “All control is good! / Apple just killed Adobe!”, what the press has missed is a sense among developers that they can’t predict or entirely interpret Apple’s developer agreements. I suspect Apple did aim this at Adobe, but that means even non-Flash-using, native-developing software makers now have to face some serious ambiguity in a legal document they have to sign.

That said, if Apple would further clarify the statement, that could be resolved.

I didn’t personally get worked up over this, because it’s consistent with what I and many, many others have been saying about the platform all along. Apple’s control over distribution and desire to control the development process means this is the sort of thing they can do. There are reasons to endure it: they make a really well-engineered platform, and there’s a terrific market and installed base that has a voracious appetite for creative software. There are also clear reasons to look elsewhere if you’re not comfortable with the restrictions. This is the very definition of trade-offs and choices.

I’m going to avoid the debate not because I don’t think it’s important – I think it is – but because I think enough words have been written in service to one side or the other. What seems to be missing, however, is a shared understanding of what cross-platform development actually is.

The Trend: “All Cross-Platform Development is Bad”

Whatever Apple’s thinking, it’s caused some people apologizing for Apple to say really weird things. John Gruber at Daring Fireball, for instance, begins by making an entirely reasonable argument for Apple’s strategy and where they live in the market. I don’t agree with all of it, but it is a well-reasoned, well-argued point. Then, almost as a footnote, John makes this claim:

Cross-platform software toolkits have never — ever — produced top-notch native apps for Apple platforms. Not for the classic Mac OS, not for Mac OS X, and not for iPhone OS. Such apps generally have been downright crummy.

[emphasis mine]

Why Apple Changed Section 3.3.1
[Daring Fireball]

That argument has gotten picked up all over the Web by other Mac fans. And that, to me, is dangerous – because, as worded, this statement appears to be to be entirely indefensible.

John doesn’t say “cross-platform compatibility layers” or “meta-platforms” like Flash and AIR. He says “cross-platform software toolkits,” and I think he means it. (Now, John, if I’m wrong, please correct me – but please stop making statements like this, because “cross-platform” is what many of your readers are coming away with.)

This would likely come as news to those who use music software. Cross-platform software frameworks are at the heart of most of the tools we use. One small but lovely example, specific to the iPhone/iPad and absolutely kosher under Apple’s new developer rules, is LibNUI, a C++ framework for building UIs. (In fact, after playing with this a bit, I may pick it up for a project on a completely different platform.) Popular iPhone apps like bleep!BOX and BeatMaker use it, but it also keeps tools like MOTU’s MachFive plug-in compatible with multiple platforms, without sacrificing native features like drag-and-drop.

If you use Ableton Live, Max/MSP, Cubase, or countless other apps, you’re using software created in cross-platform frameworks – some in-house, but using the same basic technology. Indeed, few of these applications would work the way you expected if they used exclusively “native” features and design patterns, like UI widgets that don’t fit musical applications or don’t work in live music performance.

In fact, John’s statement is so broad and over the top, I think it might even apply to tools like CodeWarrior, the developer tool and, yes, cross-platform framework that was the dominant toolset for developers in the pre-X “Classic” Mac OS era.

This matters to users, too. Sure, you may never write a line of code, but you rely on the community of people who do. Part of what gives you the freedom and flexibility to run great software on a variety of platforms, rather than being locked into just one platform, is the fact that these tools make the differences between those platforms fall into the background. Any developer who thinks this happens automatically without effort or testing is likely to give you a terrible app, but odds are, they’ll give you a terrible app regardless of what tools they’re using.

Develop Once, Run Anywhere?

Macworld editor Jason Snell also picks up the old argument about cross-platform development being inferior. (The title, I think, may be the most insightful part of this piece, but I’m not an Apple employee or investor, so I’ll let them worry about that.)

Apple against the world [Macworld]

…the develop-once-run-anywhere philosophy is something that makes more sense to bean counters and development-environment vendors than it does to platform owners and discriminating users. In the ’90s we were told that Java apps would be the future of software, because you could write them once and deploy them anywhere. As someone who used to use a Java-based Mac app on an almost daily basis, let me tell you: it was a disaster. Java apps didn’t behave like Mac apps. They were ugly and awful and weird, but hey, at least they ran on the Mac.

Ah, yes – this argument again. (It’s one of those things from the 90s that just never gets old, like Ace of Base or plaid t-shirts and pleated khakis.)

Okay, I kid, but Jason – I feel you. Actually, I feel you even as a fan of Java; the language and platform have some real power, but because of some questionable tooling atop them and questionable development practices with them, it produced some really horrible products. Such is development. (Actually, arguably, the folks in the 90s were right – it just turns out to be the browser itself, not Java applets, which have nothing to do with modern Java development anyway.)

I think Jason is mostly hung up on things like UI widgets; he refers specifically to the lack of a menu bar, odd preferences dialogs, and other usability issues in the AIR application TweetDeck. (Part of the reason we don’t nitpick these things in music, of course, is that we’re using extraordinarily complex interfaces for doing other things.)

Jason misses some critical points, however – in this case by omission; he doesn’t make the same, sweeping statement Gruber does. (Jason told me via Twitter that he wasn’t set to write another 2000 words, so Jason, I’ll try to do that for you.)

In regards to Java, the reason Java apps don’t feel like native Mac apps is at least in part because of Apple. It is actually possible to do all the things Jason is describing; Apple themselves touted the feature. You can read the documentation, and the fact that it was deprecated way back in 2005, on Apple’s legacy Mac developer documentation site. I can only speculate about the decision there, but my guess would be that it was practical more than strategic. There’s a new open source project to replace this functionality, Apple themselves recently made interfacing with native code easier for Java developers, and whatever language preferences Apple has on the iPhone, they continue to support projects like Ruby on the desktop Mac.

Generally, I think you’ll see more native feel in apps for Mac, Windows, and Linux from Java, Ruby, Python, and other languages. It’s an area of active development, and it’s improving. It may also benefit from these communities breaking off from big corporate parents, because the developers themselves seem to understand the perspective of the users better than, erm, companies like Sun and Oracle. Bottom line: don’t be surprised if some day soon you again run a Java app (or another language, not necessarily Java) and don’t notice. Those “discriminating users” on the Mac do notice when it’s wrong, and very often want to get it right.

Art, Tools, and Cross-Platform Frameworks That Don’t Suck (Or Break Apple Rules, Maybe)

But it’s not just about the standard Mac widgets. Jason, definitely check out Processing and the fantastic art made with it? It’s Java, though that doesn’t matter and isn’t immediately apparent, which is good.

If you design became only about widgets and preference bars, even nice Mac ones, we’d have a generic, bland, look-alike future for software. I know that escaping bland, cookie-cutter software is what drove a lot of people to the Mac in the first place, so it’s worth reiterating.

Tools like Java aside, though, somehow lost in this debate is the fact that cross-platform development is wildly popular and largely transparent – just in the language C/C++. From games to serious software, a whole lot of software is written in cross-platform C++, with the bulk of the code compiling on different operating systems and even hardware architectures. Developers typically make use of various frameworks to ease this compatibility.

Furthermore, while I still think there are reasons to be wary of Apple’s policies and this decision in particular, it would likely be inaccurate to claim that the recent change blocks these tools. In fact, several specific examples all use native code to link against the official Apple APIs, meaning they should be safe. These applications are exceptions that prove the rule: they’re great cross-platform tools that can produce great apps, they’re allowed on the iPhone/iPad OS as near as I can tell, and in some cases they’ll also be cranking out great apps for non-Apple platforms. Adobe’s big sin may have been allowing development from Windows, meaning you don’t get all those designers buying new MacBooks. Here are some examples of tools likely to be safe:

iPhone Wax uses Lua, but it still uses Xcode templates.

Corona, an awesome development tool for OpenGL-accelerated apps, has a specific response. Oh, and it’s coming to Android, too.

Unity is producing fantastic games and should likewise be safe under the new rules.

OpenFrameworks, a brilliant framework for artists that allows them to produce creative, interactive applications with music, visuals, and media for Windows, Mac, Linux, and platforms like iPhone/iPad is written entirely in C++ and appears to be okay. (Again, you use Xcode and Objective-C to link against official Apple APIs.)

Not incidentally, each of these tools (and LibNUI, above) could make some amazing music apps, some likely developed by readers of this site.

Let’s be clear: critics of Apple’s change likely overestimated how many frameworks would be impacted. That meant people were making an argument that may have been divorced from the facts. That said:

Just because they got the argument wrong doesn’t mean criticism (or defense) isn’t warranted. Apple did make a major change to the developer agreement, and they made it – apparently – as a reactionary response to a particular technology, in a way that could threaten other, unrelated technologies. The debate may have gotten overheated and inaccurate, but it’s understandable that the underlying cause is cause for concern. In fact, I think there’s no reason that Mac-centric media outlets couldn’t point that out. And developers really should consider leaving a platform if they don’t like it. (If it’s Apple’s right to make the rules, it’s certainly likewise the developer’s right to vote with his or her feet.) I think there’s an argument to be made in defense of Apple – I could certainly make that argument if someone dropped me on a debate team and put me on Apple’s side, even if I happen to disagree.

The jury is still out on just what apps are impacted – which should be further cause for concern. In fact, I’m still not entirely sure what the status of the apps above may be. On the blog /dev/why??:

In my opinion this is not purely aimed at Flash, but it is certainly precipitated by Flash CS5. I can’t imagine Apple is happy about environments like MonoTouch, Unity3D, PhoneGap, Appcelerator, or Corona, but I am doubtful they would have changed the license in this way just to stop developers using those environments …

He apparently thinks, however (though even the developers of Corona do not), that these frameworks could become verboten. Furthermore, he notes the case of “interpreted code” and why it’s important (it happens to be useful in music apps, too), though my understanding was that that was already a violation of the agreement. (Perhaps it’s clarified here.)

The more interesting thing from my standpoint is that this makes it a license violation to include a language interpreter inside a game. If you aren’t a game developer you might not be familiar with how large games are structured, but most games consist of a game engine, which is high performance code for doing things like rendering graphics, and an interpreter which runs the game logic (determining how sprites move, determining when to pop up in game text boxes, etc). This is how practically every commercial RPG works, as well as many (most?) other types of games. This affects major app store publishers, like EA, Gameloft, Tapulous, and ngmoco:). Looking at the top ten lists on the app store right now I see several titles that I know have embedded Lua interpreters. In this case I think these apps are genuine collateral damage, though I honestly doubt Apple would attempt to enforce the clause against them. In fact, using an interpreted language for game logic is already technically in violation of section 3.3.2 in the current agreement, though many developers may not realize it because under the original agreement it was okay, and the change that made it verboten was very subtle (changing an “and” to an “or”). I am actually not sure exactly when that changed, and only noticed it myself while I was researching this blog post.

See comments – ultimately, the language question is the big one. It could have a negative impact on developer flexibility, and specifically could impact DSP code. As Richard notes in comments, it’s all a matter of what Apple chooses to enforce. It’s possible that the letter of the law makes all of these things illegal, but in practice, Apple just wants to block Adobe’s tools.

But let’s also be clear:

Major voices in the Mac community are advocating against cross-platform software, even without a complete understanding of what that means. And you can actually defend Apple’s rule change Others (like Jason Snell at Macworld) I think just don’t get the opportunity to be clear. But let’s be clear. Let’s makes sure that idealogical discussions on both sides of this debate don’t obscure the facts.

Digging into Apple’s own, platform-proprietary tools can be a great thing. My friend vade, a sometimes-contributor on Create Digital Motion, has done great work with Quartz Composer, for instance, as an artist, and knows Core Image backwards and forwards because it allows him to express himself.

But that’s just one avenue. I know other developers who have found that working across multiple platforms ultimately makes their software better. Jason Snell unfairly, I think, characterizes this as “lowest-common denominator” development. If that’s what you’re doing, well, yeah, that would kind of suck. But I’d call this “highest-common denominator” development: the more you need to make code work on multiple platforms, the more, very often, you have to optimize all of the platforms, the more you discover opportunities to improve your code and make it a more general solution to a problem.

The truth is, you can use the cross-platform tools above to make fantastic iPhone/iPad apps, apps that feel entirely “native,” but apps that will also – by Jason’s description:

…[create] a world where App X for iPhone and App X for Android are indistinguishable from one another.

When it comes to games, to music apps, to creative applications with alternative interfaces, to immersive applications, to rich media interfaces – developers are creating that world, period. Apple can’t stop developers from doing that. Given that they tout availability of apps for their platform that were built with that model, I’m not even convinced Apple always has a problem with that development model.

The cross-platform world is here already, and it’s growing. And, honestly, I think it’ll be a good thing.

For further reading…

This post is really rhetorical, but it hilariously takes the legal clause to its logical (if not practical or likely) conclusion:
Apple bans modular programming

It’s amusing reading, but as author Jeff Erickson (“Ernie Pan”) responds to comments, the real bottom line comes out: “But it doesn’t matter what Apple means. The license is a legal document; the only thing that matters is what it actually says.” Of course, that leads to still more unpleasant revelations: it doesn’t matter what the document says or Apple means, but what Apple actually does. And Apple can change what it does at any time.

Tao Effect notes, as I do, that cross-platform toolkits can be made to look like native apps, or even that it may not matter what they look like (because as a game, or in my example of a music app, they all look different by necessity). It also responds to what I think we could now call the Jobs Doctrine:

“We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.”

My issue: I”m not sure what Jobs means by the terms “intermediate” or “layers.” In fact, I’m not entirely certain what he means by “sub-standard.”

The blog notes that – while I suggest that maybe some of them are safe – things like MonoTouch, popular apps that feature Lua scripting in their development, and the widely-used Unity 3D game framework may well not be allowed in the store, which could mean more unpredictable rejections.

Ah, to be using a game console, where almost everything is rejected and you only have to worry about the few apps that make the cut…

Whatever the implications for the iPhone platform, though, these stories underly the point I’m really trying to make here – whatever Jobs may seem to be saying or Apple advocates are arguing, the notion that cross-platform development creates bad apps is one that is seriously open to debate.

In the meantime, we have several groups who don’t speak the same language or technical understanding:
1. Apple lawyers.
2. Apple end users / customers / advocates.
3. Developers.

And then we have Steve Jobs making sweeping, provocative generalizations that are themselves enigmatic, because he’s, well … Steve Jobs. (So make that category #4.)