[Stk] Improving support for iOS

[Perry Cook]

Re-posting this to the list:

Ari:  I love your work, apps, and enthusiasm for STK!!!

I would totally support any re factorization of STK that makes it 
more useable and more modular.  I myself have tried to use just 
a class or two and found I had to play a "Whack-a-Mole" game of
#includes and errors.  And Git would be wonderful too.  

My thoughts on control changes and SKINI:

How about a simple #define SKINI
combined with ifdefs placed in the right places?
That way any classes could be used and modified
alone (or with the appropriate small number of 
dependencies), but they wouldn't look for or complain
about missing SKINI.

It's possible that other dependencies necessary for the full
demo version of STK, but not required for putting together
small projects, could be similarly dealt with by adding some
#defines and #ifdefs?

My thoughts on first blush.

Prc

Sent from my iPad :-)

On Sep 10, 2013, at 6:41 AM, Gary Scavone <gary at ccrma.Stanford.EDU> wrote:

> Dear Ariel,
> 
> Thanks for your suggestions, enthusiasm, and offer to help!  Your email is timely because it is becoming harder and harder for me to find the time to properly support STK (and RtAudio and RtMidi).  So, I agree that STK should go into GitHub.  I don't have prior experience starting a GitHub project … are there any particular things I should pay attention to?
> 
> I agree with most of your suggestions, though I'd like to hear Perry's opinion about SKINI.  I think the controlChange function is useful because it shows how one would go about using the various class-specific parameter update functions, as well as providing a simple, common function to experiment with the various Instrmnt classes.  If we took out the controlChange function, many of the current demos would cease to work.  And if we hose SKINI, we'd still need to use some sort of control scheme.
> 
> Another thing that needs to happen is that RtAudio and RtMidi need to be extracted to separate GitHub projects, as there are many people that want to build those as shared libraries and not have redundant versions in the STK folder.  Then we need to find a way to allow them to be easily used within STK without necessarily bundling them in STK.
> 
> --gary
> 
> On 2013-09-10, at 8:51 AM, Ariel Elkin <arielelkin at gmail.com> wrote:
> 
>> 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
>