Intro
Over the last 5 years, I've released 9 major versions of tappr.tv, with each release having a specific theme:
- Wands = basic input-output architecture
- Loops = recording and playback
- Dances = recording and playing back in time with a song
- Community L1 = publish dances and subscribe to favorite artists
- Effects and Inputs = symmetry mode, audio in, TouchOSC
- Live = dynamic BPM-based loops, network IO for real-time multi-device input
- Remix = enable members to remix a dance, adding tracks, and changing effects and wands
- Parallax = modernize the UI for iOS 7 and enhance the dynamic rendering of dance tracks thru parallax effects.
- Community L2 = subscribe to other members, receive push notifications of significant events
And as always, I've got a roadmap in mind for the future of tappr.tv:
- 3D
- Apple TV
- Web
- Playlists
- Wands
- OSC
But, in order to keep marching forward, I have to address continuously evolving platform requirements. Specifically, Apple has mandated that all iOS apps be 64-bit compatible. At this point, I can't submit new builds until this compatibility is met.
Fortunately, I think I can knock off two birds with one stone…
Getting to 64-bit
The move to 64-bit involves updating the code to properly hold number and pointer values, which is fairly easy, as well as updating any third-party libraries to 64-bit builds, which can be problematic.
One of the biggest third-party libraries in use by tappr.tv is Cocos2D. All of the wands in tappr.tv are really just sets of parameters to a high-performance particle emitter system. For a variety of reasons, I'm still using a version 1 of Cocos2D, which obviously doesn't have any of the niceties found in later builds, like support for OpenGL ES 2.0, programmable pipelines, or 64-bit support.
I'm also interested in getting to 3D. Cocos2D has a companion project called Cocos3D, which I successfully used in Cosmogony startled applet in the björk Biophilia app, and I'm glad to see it has moved forward as an open-source project.
But moving to later builds wouldn't be trivial, as there are significant changes to the API. And as Apple continues to relentless push forward with their platform technologies, relying on third-party libraries has become more and more of a liability.
Therefore, I think the time has come to replace Cocos2D with SceneKit.
Getting to SceneKit
SceneKit is a 3D object graph API built on top of OpenGL. It provides a high-level object-oriented framework for nest-able nodes, shapes, scenes, lights, and cameras, as well as low-level access to the OpenGL context. In sum, it provides everything I'll need to carry tappr.tv far into the future.
Implementing tappr.tv in SceneKit has unique challenges. The most significant is finding a way to implement the same particle emitter engine as Cocos2D, to best preserve the look and feel of existing dances. Fortunately, SceneKit offers a RenderDelegate protocol that should make porting the OpenGL code inside CCParticleSystem fairly straightforward. Of course, time will tell if its as easy as I make it out to be.
Once the core visuals have been ported, the next challenge will be to extend the event IO structure of dance tracks to include three dimensions, as well as to enable more kinds of render nodes beyond wands, such as camera and light nodes.
In the tappr.tv Theater, I can imagine a control somewhere around the stage that lets you toggle between dancing along with your own wand, or navigating around the space while the dance plays. And I can imaging integrating the GameController framework so that you can navigate with a controller with 6 degrees of freedom.
Conclusion
Re-implementing the wands of tappr.tv in SceneKit should make it much easier to achieve 64-bit compatibility, as well as set tappr.tv up for exciting new features in 3D. Stay tuned…