[Stk] Improving support for iOS

[Ariel Elkin]

The STK is one of the most useful open-source libraries available for audio synthesis and processing. One of its aims is cross-platform functionality, and one of the platforms where it's had a lot of success is iOS. Ever since MoMu-STK, many iPhone and iPad apps based on the STK have seen the day (I myself have used the STK in four of the apps I've released or helped release on the App Store). And the number of iOS developers requiring or just interested in audio synthesis on iPhones and iPads is large and expanding. 

The field of mobile music music-making is worthwhile and expanding, and iOS being one of the platforms of choice, the STK's should fully support it.

There's specific interest in the STK for iOS. I've had over 5,000 unique visitors on the STK tutorial I wrote for iOS: 
http://arivibes.com/realtime-audio-on-ios-tutorial-making-a-mandolin/
And people regularly email me asking for more tutorials.

But the STK's current support for iOS is below par. Although iOS can speak C++, the Toolkit has some design attributes that make it incompatible with iOS. If an iOS developer drags and drops the current STK release (v4.4.4) into Xcode, dozens and dozens of build errors start stemming from the STK classes. Fixing them is unfortunately not a trivial task.

There's the possibility of using MoMu-STK, but that ported v4.4.2. The MoMu project is ostensibly no longer maintained (the only version released was in 2009), so the bug fixes and new STK classes that came with later versions aren't included. Additionally, MoMu-STK generates something like 80 compiler warnings. MoMu-STK is not really a good alternative.

So let's improve the STK's support for iOS. I thought of several enhancements that would improve the STK's support for iOS, AND make it easier to create ports for other platforms:


A) GROUP AUDIO CLASSES SEPARATELY
Clearly separate the STK's audio classes from the STK's helper classes. Classes solely dedicated to audio purposes (e.g. Sitar, PRCRev, etc.) should be grouped in their directory. The STK's helper classes, such as those for networking (e.g. Socket, TcpClient) multithreading (e.g. Mutex), or audio layer setup (e.g. RtAudio), should be in separate directories. 

STK users should be able to easily select and drag and drop just the strictly necessary audio classes. This is because platforms such as iOS already provide APIs that effectively supersede the STK's helper classes.


B) DON'T MAKE AUDIO CLASSES DEPEND ON SKINI
The STK's audio classes (the Instruments in particular, such as Clarinet, Flute, Moog, etc.) should no longer be dependent on SKINI (Synthesis toolKit Instrument Network Interface). The SKINI protocol is a venerable instrument controller system, but nowadays many STK users are more likely to write their own control change functions using the STK Instruments' current functions. The STK's Instruments' controlChange() function is thus redundant to a lot of users. 

Ideally, get rid of SKINI and controlChange() functions altogether. If the STK's Instruments MUST keep their controlChange() function, then don't force users to import SKINI every time they want to use an STK class!


C) DEFINE MACROS FOR IPHONE
Add a #define macro for __OS_IPHONE__ at the bottom of Stk.h. This may come in very handy in later updates to the Toolkit, and will at least allow a clean way to fix the rawwaves directory. 


D) EXAMPLE PROJECTS
Add example projects that show how to use the STK using the latest IDEs. Include an example project for iOS that uses Xcode 4!


E) GITHUB
Put the STK on GitHub! Give us a good reason not to? Putting the the STK on GitHub will increase its visibility, facilitate the release of quick fixes, and attract code contributions from other developers. It's easy and free. 




I have been working on an Xcode project that illustrates some necessary steps to modify the current STK to get it to work on iOS:
https://github.com/arielelkin/STK-on-iOS

You can see more details in its commit history. But I don't really want that repository to become a *port* of the STK. The big disadvantage of making a port is clear: every time there'll be an update of the STK, the update will have to be manually merged into the port! I see the above Xcode project as a transitory thing, the idea behind it is to help integrate those changes INTO the STK so that it fully supports iOS. 

I'd be happy to give a hand with this. 


Dear maintainers of the STK (Gary, Stephen, Perry), dear users of the STK, what are your thoughts? 


Cheers,
Ariel