[Stk] STK Repository structure

[Gary Scavone]

Hi Ariel,

I'll make some comments on your proposed restructuring below but for the moment, we're still trying to finalize the structure of the github repo before moving forward with changes.

I'm happy to consider a reorganization of the directory structure if there is a good motivation for doing so and if it can be done cleanly.  But in the structure you proposed, "classes" is rather generic and doesn't have much meaning (since nearly all the files are "classes").  And what does "audio class" mean?  We have sample source classes (the Generator subclasses), Filter classes, audio I/O classes (such as WvIn/WvOut), Instrmnt classes, …

I'd also like to remind you that STK was intended as a cross-platform system that would work, as much as possible, in the same way on all supported OS's and systems.  Both Perry and I got burnt in the past developing code for systems that went belly-up and STK was specifically designed to help avoid that from happening again.  Thus, while it is good to support iOS, I don't want to do that at the expense of the other supported systems.  And moving the projects into system-specific directories goes against the whole idea of STK … they are supposed to work on _all_ supported systems.  Classes such as RtAudio, RtMidi, Thread, Mutex, Socket, … are meant to provide corresponding functionalities to users while hiding the platform dependencies.  Potentially, RtMidi and RtAudio could support the iOS audio and MIDI layers, as those classes do support CoreMidi and CoreAudio.  The RtWvIn and RtWvOut classes are meant to provide an easier-to-user audio IO interface for users (though they are not as robust to dropouts as using RtAudio directly).

I can't help but think that your problems in using STK in iOS are more caused by Xcode, not STK.  There is an option in the configure script to exclude "realtime" classes (essentially, all classes containing system dependencies) from being compiled.

That all said, it could make sense to do some reorganization.  I don't have a lot of time at the moment to think about this, but it could be ok to put classes that contain platform dependencies into something like a "utilities" directory.  It also might make sense to add some system-specific directories for example projects, as long as they are not too large.

--gary

On 2013-10-09, at 10:34 AM, Ariel Elkin <arielelkin at gmail.com> wrote:

> Hi Steve,
> 
> There's several reasons for which a reorganisation would be helpful, especially for iOS developers:  
> 
> 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 various STK files which are redundant on iOS or incompatible with it.
> 
> For example, TCPClient is superseded by Apple's Foundation's networking classes, and RtAudio, RtWvOut, etc. are superseded by Apple's Core Audio audio layer classes. 
> 
> These are all the STK's files that are redundant on iOS:
> 
> Multithreading:
> 	• Thread.h
> 	• Thread.cpp
> 	• Mutex.h
> 	• Mutex.ccp
> Networking:
> 	• UdpSocket.h
> 	• UdpSocket.cpp
> 	• Socket.h
> 	• Socket.cpp
> 	• TcpClient.h
> 	• TcpClient.cpp
> 	• TcpServer.h
> 	• TcpServer.cpp
> File I/O:
> 	• InetWvOut.h
> 	• InetWvOut.cpp
> 	• InetWvIn.h
> 	• InetWvIn.cpp
> Audio Layer setup:
> 	• RtAudio.h
> 	• RtAudio.cpp
> 	• RtMidi.h
> 	• RtMidi.cpp
> 	• RtWvIn.h
> 	• RtWvIn.cpp
> 	• RtWvOut.h
> 	• RtWvOut.cpp
> 	• RtError.h
> In rawwaves/
> 	• makefun.c
> 	• makemidi.c
> 	• makewav.c
> 	• sine.c
> 
> See https://github.com/arielelkin/STK-on-iOS
> 
> In the current state of the repository, an iOS developer has to manually select and remove each of the above files, because ALL of the STK's source files are in the /src and /include folder. 
> 
> Which is why I suggest moving those files to a /Utilities folder, and the core STK audio files to a /STK folder.
> 
> Then there's the current /projects folder, containing awesome projects but which don't run on iOS due to their dependence on RtAudio. That frustrates an iOS developer. Hence my suggestion to group projects within the /projects according to the platform they run on. 
> 
> So the directory changes I'm proposing would not only make it easier to support iOS, it would make it easier to support other platforms too! 
> 
> Ariel
> 
> 
> On 9 Oct 2013, at 3:37pm, Stephen Sinclair wrote:
> 
>> Hi Ariel,
>> 
>> I think this deserves a response, but I think the reason no one is
>> jumping at it is that it's not clear why a re-organization is
>> necessary.  That doesn't necessarily mean it's a bad idea, just that
>> it doesn't seem obvious to me.
>> 
>> For example, what is it about moving source files to different
>> directories that would make it easier for supporting iOS?
>> 
>> Steve
>> 
>> 
>> On Tue, Oct 8, 2013 at 2:04 AM, Ariel Elkin <arielelkin at gmail.com> wrote:
>>> Great to see the STK git repository is coming along!
>>> 
>>> I think that something that would really improve the STK's support for iOS, AND make it easier to create ports for other platforms, is if we 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.
>>> 
>>> I thought about this 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 (e.g. RtAudio)
>>> Utilities/Multithreading
>>> Demo/OSX
>>> Demo/Windows
>>> Demo/iOS
>>> 
>>> Let me know if you have comments or suggestions!
>>> 
>>> Ariel
>>> 
>>> _______________________________________________
>>> Stk mailing list
>>> Stk at ccrma.stanford.edu
>>> http://ccrma-mail.stanford.edu/mailman/listinfo/stk
>>> 
>>> 
>> 
>> _______________________________________________
>> Stk mailing list
>> Stk at ccrma.stanford.edu
>> http://ccrma-mail.stanford.edu/mailman/listinfo/stk
> 
> 
> _______________________________________________
> Stk mailing list
> Stk at ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/stk