[Stk] Improving support for iOS

Stephen Sinclair sinclair at music.mcgill.ca
Wed Sep 11 07:03:56 PDT 2013 

Hi Ariel,

Which large, non-source files are you referring to?

The only non-text files in the repository are the .raw files, which I
would argue do belong to STK and should be in the repository.  As well
as a few small .xbm files used in the demo application.

Currently for me,

sinclairs:~/projects/stk
$ du -sh .git
6.2M .git

$ du -sh doc
328K doc

$ du -sh rawwaves
392K rawwaves

which is not overly large, certainly not the 27M you are claiming.

In any case, I would prefer to do any refactoring in a
version-controlled way.  If later you want to remove some old files
permanently, you can use various git tools or start a new repo, but I
don't see why you'd initially just not keep track of what you are
doing.

Of course, you are free to do what you want and propose it, I am only
making suggestions.

Steve


On Wed, Sep 11, 2013 at 3:49 PM, Ariel Elkin <arielelkin at gmail.com> wrote:
> It'd be fine to use Git for the refactoring if the codebase didn't currently contain so many large files that are not source code, but it's not the case. It's a problem because Git keeps a copy of every file you add to a repository, and if during refactoring we remove and then add large files, the repository will just unnecessarily increase in size.
>
> Here's the scenario:
>
> We make a git repository out of the current STK directory. That directory is already a whooping 22.2MB, its contents are added to the repository, so the repository will never go below 22.2MB. Which is a lot. Suppose that in the next commit we decide to remove the docs folder (which is 5.7MB). We make a few more commits, then we decide (for whatever reason) to add the docs folder back to the repository. That'll increase the repository's size by 5.7MB (to a total of over 27MB)!
>
> GitHub too warns against using git to track non-source files:
> https://help.github.com/articles/what-is-my-disk-quota
>
> Also see:
> http://stackoverflow.com/questions/5756324/how-do-i-handle-images-in-a-git-repo
>
> Finalising the list of files that'll go in the next STK version might take several revisions, and making those revisions will probably cause unneeded repository bloat. Which is why I suggested to provisionally use Dropbox to make just those revisions, then make the git repository once we have a canonical version.
>
> At any rate, I think we should let's settle on the file organisation first, then decide what the best way to implement the change is… Here's the suggestion I made previously (with a little change in directory structure):
>
> STK/Classes                             <-- All the audio classes, both .h and .cpp (e.g. Guitar, Mandolin, Twang)
> STK/Rawwaves                    <-- All the raw waves
> Utilities/Networking            <-- All the networking classes
> Utilities/IO                            <-- All the file I/O classes
> Utilities/Multithreading
> Example/OSX
> Example/Windows
> Example/iOS
>
> How does this directory structure
>
> There's a couple of other matters:
> 1) Should the repository contain a documentation folder? It's over 5MB… The STK's online documentation is pretty good!
>
> 2) These guys in rawwaves/
> makefunc.c
> makemidi.c
> makewavs.c
> sine.c
> could go in Utilities/
>
> 3) The guys in src/include could go in Utilities/Asio
>
> 4) The guys in src/Debug weigh a lot… Are they really necessary?
>
>
> Ariel
>
> On 11 Sep 2013, at 7:55am, Stephen Sinclair wrote:
>
>> Hi, I think this discussion can be kept on the STK list, no?
>>
>> In any case, without thinking too much about the proposed "directory
>> structure" the only point I really disagree on is that we should agree
>> on the directory structure before initializing the git repository.
>>
>> The whole point of git is to track changes.  This refactoring proposal
>> constitutes a change that can be perfectly well tracked by git.
>> Indeed, git will make it that much easier, by allowing to show how
>> files have moved around since the previous version.
>>
>> So I think a git repository based on the current file organization,
>> whether it's the one I already created or not, should be used as the
>> basis for this change, and the changes should be tracked.
>>
>> Steve
>>
>>
>> On Wed, Sep 11, 2013 at 4:19 AM, Ariel Elkin <arielelkin at gmail.com> wrote:
>>> Hey Gary,
>>>
>>> Thanks for your reply!
>>>
>>> Yep, I agree that RtAudio and RtMidi should be in their own repository. As Steve said, I'm not sure if they should be submodules of the STK (or vice-versa), given that they don't necessarily depend on each other and that they can be seen as distinct projects. I'd make it clear in the Readme for each project where to find the other project if need be.
>>>
>>> About GitHub: GitHub accounts can belong to an individual or to an organisation. For a library with several maintainers, organisation accounts might make more sense, e.g.:
>>> https://github.com/thestk
>>>
>>> So the STK could be somewhere like:
>>> https://github.com/thestk/stk
>>>
>>> Just like
>>> https://github.com/TheAmazingAudioEngine/TheAmazingAudioEngine/
>>> or
>>> https://github.com/AFNetworking/AFNetworking/
>>>
>>> First, setup your individual GitHub account.
>>> https://github.com/signup/free
>>>
>>> Then setup an organisation account:
>>> https://github.com/organizations/new
>>>
>>> GitHub has excellent documentation on how to push a repository to their servers:
>>> https://help.github.com/articles/create-a-repo
>>>
>>>
>>> Before initialising the git repository, let's think about what the directory structure and file list should be…
>>>
>>> Here's one suggestion:
>>>
>>> STK/Audio/Classes               <-- All the audio classes, both .h and .cpp (e.g. Guitar, Mandolin, Twang)
>>> STK/Audio/Rawwaves      <-- All the raw waves
>>> STK/Utilities/Networking        <-- All the networking classes
>>> STK/Utilities/IO                        <-- All the file I/O classes
>>> STK/Utilities/Multithreading
>>> Example/OSX
>>> Example/Windows
>>> Example/iOS
>>>
>>> There's a couple of other matters:
>>> 1) Should the repository contain a documentation folder? It's over 5MB… The STK's online documentation is pretty good!
>>>
>>> 2) These guys in rawwaves/
>>> makefunc.c
>>> makemidi.c
>>> makewavs.c
>>> sine.c
>>> could go in STK/Utilities/
>>>
>>> 3) The guys in src/include could go in STK/Utilities/Asio
>>>
>>> 4) The guys in src/Debug weigh a lot… Are they really necessary?
>>>
>>>
>>> One thing we could do is start a Dropbox folder where we can work on the file list and directory structure, and once that's finalised we can make a git repository out of it. What do you think?
>>>
>>> Ariel
>>>
>>>
>>> On 10 Sep 2013, at 3:41pm, Gary Scavone 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
>>>>
>>>
>>>
>>>
>
>
> _______________________________________________
> Stk mailing list
> Stk at ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/stk
>
>

More information about the Stk mailing list