[Stk] Improving support for iOS

[Richard Dobson]

On 10/09/2013 13:51, Ariel Elkin wrote:
...
> 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.
>
...
>
> 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:
>

My approach to this issue was just to make a static stk library for iOS 
out of the stk classes, leaving out the real-time audio files (as of 
course I would be using the native iOS audio framework with callback). 
This was in pre-MoMu days. I can't say I remember lots of compiler 
errors (this was with v 4.4.2 of stk, and done initially with Xcode 3., 
and later converted to use Xcode 4 (Snow Leopard)). For my initial 
project (based on playing samples algorithmically) I only needed one 
"raw" file, so I just included that in the source directory and it all 
gets built into the final executable. Then it is just a matter of using 
the standard NS~ routines to obtain the path to the installed app, and 
appending (in this case) my file name. Clearly the whole RAWWAVES path 
can be included in the project directory in the same way, and the Stk 
function to set the rawwave path invoked accordingly.

With this done, for any new project it is a simple matter to link to the 
static stk library, rather than worry about including specific stk 
source files each time. It may well be a reasonable idea to restructure 
the stk sources anyway (separating out the audio classes for those times 
when one is using something else - portaudio etc), but for iOS I would 
recommend the static library route.

Richard Dobson