[Stk] iOS static library

[Gary Scavone]

I am in complete agreement with Richard’s thoughts on this.  There currently exists a way to set the RAWWAVE_PATH during compilation (using a preprocessor definition) but this was done mainly for the demo programs.  The setRawwavePath() function exists exactly for the purpose you need and should be one of the first statements in a program making use of STK classes that use those files.

As might be obvious, I find I have less and less time to support and maintain STK.  Thus, it is important that future developments don’t make that process any harder.

Regards,

—gary

On Mar 12, 2014, at 6:39 AM, Richard Dobson <richarddobson at blueyonder.co.uk> wrote:

> On 12/03/2014 03:49, Ariel Elkin wrote:
> ...
>> 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.
>> ...
> 
> I disagree with this - I think it is the app's responsibility - partly 
> because it already has that responsibility for so many other resources.
> As the developer, I would also want to have explicit control of the 
> process in my app code.
> 
> Have you seen this blog page about packaging resources in a bundle:
> 
> http://www.galloway.me.uk/tutorials/ios-library-with-resources
> 
> 
> There are two aspects I get from this. Firstly, using code to load 
> resources at runtime is something iOS programmers are already doing 
> almost as a matter of routine (see the example towards the bottom of the 
> page), so requiring the developer to add another line to obtain the 
> rawwaves path is hardly taxing or burdensome.  If such a thing is too 
> difficult, using the STK may be even more difficult!
> 
> Secondly, I noticed this comment, which reflects a concern I have:
> 
> "Can I distribute my app, this way? Because when validating the archive 
> I get the message that my app does not contain a single-bundle 
> application (I guess because of the static library bundle?)"
> 
> A custom resource bundle is a perfectly elegant idea in principle. 
> However, Apple has rather strict rules about what constitutes a valid 
> iOS app (e.g. no custom dynamic libraries), and adding a resource bundle 
> (even though it only contains soundfiles) sounds like it could be a 
> problem. I don't know for sure, as I have yet to get as far as 
> submitting an app. But I think you need to be ready for the possibility 
> that this may not be accepted.
> 
> I am also not aware of a C or C++ API which can be used in a .cpp file 
> to find the apps bundle directory, so (as I suggested before) it may not 
> actually be possible to add something to Stk.cpp which would do the job. 
> I am still puzzled as to why you think adding a handful of lines to the 
> ~AppDelegate.mm etc is something to avoid. It would apart from anything 
> else be an important and early component of a curriculum for teaching 
> app design in schools, which is already happening here and there, as 
> part of the general programme for teaching CS. This is something we in 
> CDP are actively working on.
> 
> So I remain of the opinion that the most straightforward way to manage 
> things is to build the STk static library, copy it to your app project, 
> likewise copy the rawwaves folder to your app bundle (root, or inside 
> "resources", whatever), add the code to find the app path, and init Stk 
> accordingly. No modification to STk source files or headers needed, and 
> no danger of an added bundle breaking Apple's rules.
> 
> Richard Dobson
> 
> ** see e.g. http://people.bath.ac.uk/masrwd/smcs/smcslinks.html
> 
> _______________________________________________
> Stk mailing list
> Stk at ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/stk