[Stk] iOS static library

[Ariel Elkin]

Hi all,

I’ve been doing a lot of thinking about possible ways to treat the STK’s rawwaves component on iOS. 

There’s two main problems to solve: how to package them, and how to tell the STK where they are. 

A) Packaging. 

The STK being entirely open source, a developer always has the possibility to hand-pick the classes and raw waves needed for a specific project. In this use-case, the developer hand picks the individual raw waves needed. That said, the STK’s current build system does provide the possibility to build the STK as a library. In this use-case, should the raw waves be included in the library that’s built? From what I can see from the current build scripts, the raw waves are indeed included. And this makes sense, it’s consistent with it being a static library, it minimises the set up time that "naive users” (which Perry mentioned earlier on) have to be confronted with (many (i.e. 14) STK’s classes rely on the raw waves to function), it makes for faster prototyping, etc. 

Now, as comprehensive as an STK Cocoa Touch library may be, it cannot include files that are not code. The normal way for Cocoa Touch libraries to provide a non trivial amount of resources (such as images or… audio) is to package them as a (Cocoa) Bundle, which is what I’ve done. The setup is a single (necessary) drag-and-drop using a familiar Xcode object, instead of a drag-and-drop for every individual raw wave file needed. 

Again, a developer may drag and and drop any and all STK raw waves needed instead of using them as part of the static library. But offering them as an additional single component of the static library is more useful than not. 

B) Telling the STK where the raw waves files are. 

14 STK classes need to know where the raw wave files are. Currently, the STK sets the raw wave path at compile-time, and this works fine for platforms where such paths can be statically determined. 

But there are platforms where #define RAWWAVE_PATH "../../rawwaves/“ (Stk.h, line 523) won't work , and iOS is one of them. In iOS, the path to an app’s resources is known at runtime, you can’t set it as a preprocessor macro. 

So for the STK to support platforms that dynamically load resources, it needs to be told at runtime where the raw wave files are. I’ve updated my pull request with a proposed solution to do this. My solution is the following:

1) Add a preprocessor macro in Stk.h to indicate we’re on the relevant platform (note that the __APPLE__ macro is known to LLVM and GCC).

2) In Stk.cpp, if the macro is present, add a function that dynamically finds the raw wave path accordingly, and then calls Stk::setRawwavePath(). 

It’s an implementation similar to what’s in Stk :: sleep(). 

I did my best to make this implementation consistent with the STK’s patterns, but I realise there are other ways to do it. For instance, there could be an additional macro for platforms with dynamic resource loading, or the path resolution code could be placed elsewhere, etc. 

At any rate, I do think it makes more sense to have the STK dynamically resolve the raw wave path, rather than require the user to manually call setRawwavePath(). It’s a static library’s responsibility to know where its resources are. It goes without saying that it has to be done elegantly, and I’m sure we can find a way to do it so. 

Looking forward to hearing your thoughts,

Ariel  

On 10 Mar 2014, at 09:54, Richard Dobson <richarddobson at blueyonder.co.uk> wrote:

> On 10/03/2014 01:42, Ariel Elkin wrote:
> ..
>>>> 
> The oldest standard which will compile STK (c89?)? But this only matters
>>> if you are trying to distribute a binary library. This might be a
>>> bit on the generous side!
>> 
>> So if I understood you correctly you’d recommend C89? What do you
>> mean by it being on the generous side?
>> 
> 
> Deciding on a C/C++ standard only matters if you are aiming to 
> distribute a pre-compiled binary library. That is what I suggested was 
> on the generous side. And, I would also suggest, unnecessary. Stk is 
> distributed in source form, and the developer will naturally use 
> whatever compiler standard suits their project, and matches what their 
> version of Xcode can support. I don't "recommend" C89, I was just 
> speculating on whether Stk would build under C89. The more you poke 
> around making decisions on behalf of developers, the more they have to 
> poke around finding out what they are and maybe changing them again. 
> Write a README file instead!
> 
> 
>>> 
>>> 
> ..
>>> 
>>> In any case one must assume that developers will want to [be able
>>> to] tweak the contents of rawwaves as their app requires - whether
>>> by removing unneeded waveforms or by adding other custom ones. So
>>> the rawwaves folder should not built into the library itself.
>> 
>> That sort of developer indeed won’t require or use a rawwaves bundle.
>> But I honestly believe that most iOS developers out there, especially
>> if new to the STK or DSP, will just want to use, say, Mandolin, Moog,
>> or Rhodey, out of the box; so why force them to manually add each raw
>> wave required for that? Other people already observed that it’s best
>> to build everything rather than requiring developers to manually
>> figure out all the STK files’ dependencies. The way I’m building the
>> static library is so that copying the rawwaves bundle is required
>> only if you’re using a class that uses them, and even then it’s just
>> an extra 282KB.
> 
> I think you are trying to hand-hold developers too much. It is 
> (relatively speaking) the simplest of things to add the library binary 
> to an Xcode project (along with whatever other libraries they may happen 
> to need), and the most that would be needed would be a tiny bit of extra 
> documentation to that effect (that README file). Absolutely no need to 
> embed it in any library code, and certainly no need to modify any of the 
> STk code itself. The Stk may (as a library) be relatively unusual in 
> making use of an "external" folder containing sample files, but I think 
> that is reasonably clear in the existing documentation. They have to 
> manage this generally, not only when developing for iOS.
> 
> 
> ..
>> But adding #include <CoreFoundation/CoreFoundation.h>
>> 
>> to Stk.cpp elicits several errors in Core Foundation itself… So, any
>> ideas on how can I make use of Core Foundation types in Stk.cpp?
>> 
> 
> I think this is a wrong route to follow, and in the present context 
> unnecessary.
> 
> Richard Dobson
> 
> _______________________________________________
> Stk mailing list
> Stk at ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/stk