[Stk] Improving support for iOS

[Stephen Sinclair]

Hi,

If you're interested in using git, which I think is a great idea, I'll
just note that some time ago I built a git repository based on all the
previous STK tarball releases.  Since then I have not necessarily kept
it up to date, so it could use a bit of work, but feel free to fork
it.

http://github.com/radarsat1/stk

It is organized into two branches, "master" and "upstream", where
"upstream" is intended to exactly reflect the STK tarball releases,
and "master" is intended to contain some proposed patches and
improvements that have not yet been integrated "upstream", if you get
it.  This may be a slightly backward approach, depending on how you
like to work.

(Many projects consider "master" to be the canonical release, and use
branches for topic work -- this is a perfectly good approach that I
use on many projects.)

As for separating RtAudio and RtMidi, this is not a bad idea.  One
method is to use "git submodules", which basically is a mechanism for
saying that a folder within a git project is actually tracking a
separate dependent repository.

While a good idea, working with submodules can sometimes be
frustrating for various reasons.  I won't go into detail why, but just
to say that I suggest playing with the feature a bit before deciding
to use it on a real project.

Another approach is to simply consider them completely separate
projects, and make the "configure" step of STK check that RtAudio and
RtMidi are already installed.

Steve


On Tue, Sep 10, 2013 at 3:41 PM, 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
>
>
>