Argos Interface Builder, v0.20 from Dimitri Diakopoulos on Vimeo.

You know the game: you decide you want exactly 8 knobs and 10 faders. But your hardware interface has 8 knobs and 8 faders. And then you realize you could use 4 more knobs.

The appeal of touch interfaces is clear: you get controls that grow and change. So now, a generation of mobile apps is working on giving you that flexibility on touch devices. The iPhone is just the start: now the iPad, with greater real estate, will go head to head with 5″, 8″, and laptop-sized screens running Android, Linux, and Windows.

Argos is an early-stages (but usable), free and open-source tool that could help you be ready. Built in openFrameworks, the C++-based cousin to Processing, the app lets you drag in basic widgets like buttons, sliders, toggles, and x-y pads, and assign them to OSC. That opens up control to various music and visual apps. (The OSC assignment tool does bear some similarity to that on the Lemur, though it’s simpler.) The openFrameworks roots should make this easier to port to multiple platforms.

Developer Dimitri Diakopoulos, a BFA student at CalArts, is looking for developers and actively working on making this work on the iPad and its additional screen real estate – with other platforms possible, too. (If some of the PC “slate”s simply run Windows 7, you might be able to just switch the thing on, no port required — and run the app you’re controlling on the same machine if you so choose. We’ll have to wait to see what ships.) Stay tuned for more news on this, but this is well worth a look now. (Synthtopia was on top of the story earlier today.)

I’m personally interested to see if the protocol established by open iPhone app mrmr could allow over-the-air template sharing, and whether all these apps can interoperate with TUIO, the touch protocol developed for the reacTable. I said it earlier today, but there is some real potential in convergence, so I invite anyone who wishes to join that conversation. The trick is, you want to initially let people do their own thing, but then take all those “my own thing” solutions and put them together into an actual standard. If you try to impose the standard first, it might not actually work in the real world, but if you fail to standardize, you lose the advantage of interoperability. On the other hand, I think this very quandary is best solved by small groups of passionate developers, not overly-formalized process.