[Stk] iOS static library

[Ariel Elkin]

Hey Richard,

Thanks, please see below for my comments. 

On 8 Mar 2014, at 23:46, Richard Dobson <richarddobson at blueyonder.co.uk> wrote:

> On 08/03/2014 18:14, Ariel Elkin wrote:
> ..
>> I have two issues I could use some feedback on now:
>> 
>> 1) Is there a particular C dialect I should chose for it? The current
>> choice is GNU11, but these options are also available:
>> https://developer.apple.com/legacy/library/documentation/DeveloperTools/gcc-4.2.1/gcc/C-Dialect-Options.html
>> 
> 
> 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? 

> 
> 
>> 2) As you can see from the Readme’s troubleshooting section on Raw
>> waves,
>> https://github.com/arielelkin/stk/blob/ios_lib/STK%20for%20iOS/README.md#raw-waves
>> 
>> I’m having some trouble having the STK automatically set the
>> RAWWAVE_PATH macro. Basically, when running on iOS, we need
>> RAWWAVE_PATH to be set to: [[[NSBundle bundleWithURL:[[NSBundle
>> mainBundle] URLForResource:@"rawwaves" withExtension:@"bundle"]]
>> resourcePath] UTF8String]
>> 
>> but this can only be resolved at runtime, and correct me if I’m
>> wrong, this means I can’t do that with an #ifdef. So now I’m just
>> setting it manually by calling Stk::setRawwavePath at runtime.
>> 
>> Is there a way to have the STK automatically set the raw wave path to
>> the raw wave bundle?
>> 
> 
> I think you have  answered your own question. It indeed needs to be done 
> at application level, at runtime, and it necessarily involves the use of 
> approved iOS Objective C methods.
> 
> 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. 

So having a rawwaves bundle would really be consistent with the iOS static library. 

As far as implementing that goes, I think there needs to be code added to Stk’s constructor that sets the raw wave path to the raw wave bundle if we’re running on iOS. This is how MoMu-STK did it, they added this code in Stk's constructor:  

	std::string path([[[NSBundle mainBundle] resourcePath] UTF8String]);
	setRawwavePath( path );

Nice and easy, but of course those Objective-C calls forced them to rename Stk.cpp to Stk.mm, and I don’t think that’s a great option for us. 

Now, although this does need to be done at runtime if we’re on iOS, using Objective-C is not necessary, as it can be done with CFBundle’s C functions:
https://developer.apple.com/library/ios/documentation/CoreFoundation/Reference/CFBundleRef/Reference/reference.html

And C++ files in Cocoa projects can #include <CoreFoundation/CoreFoundation.h> and make use of its C types. So we can have our cake and eat it too. 

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?

Cheers

Ariel