[Stk] Improving the directory structure

[Stephen Sinclair]

I think this is a good proposal, in the sense that if we do want to
organize things in such a way, then the proposed dir structure is a
good one.

I still don't really understand however why you advocate compiling the
source files for each project instead of just including libstk.so as a
dynamically-linked library in your project.

But in any case I think this directory structure isn't a terrible
idea.  To play devil's advocate though, the main disadvantage is that
when you are looking for a particular class, instead of just typing
the first few letters of the class name and "tab", you now have to
figure out which directory it is in... I hate poking around directory
structures instead of just going right to the file itself.

Ariel, are you also proposing to organize the 'include' directory this
way?  It would be a rather backwards-incompatible change.  (That is,
all software using STK would need to add the directory to its
"include" lines.)  That said, I would also propose adding an "stk"
directory to the include folder, so that when header files are
installed to the system they appear in "/usr/include/stk".  Programs
using libstk should have lines such as,

#include <stk/Stk.h>

instead of,

#include <Stk.h>

I feel since there are so many headers, this would help to "namespace" things.

Steve


On Sun, Jan 12, 2014 at 6:03 AM, Ariel Elkin <arielelkin at gmail.com> wrote:
> Hi guys,
>
> Now that the STK's GitHub repository is established, I'd like to offer some motivations for improving the STK's directory structure.
>
> One of my favourite features of the STK is its modularity. There's a clear loose coupling pattern; synths and filters, for instance, nicely encapsulate their functionality. Functionality across the source files is widely (and wisely) distributed.
>
> Yet its directory structure, doesn't really reflect that.
>
> Currenltly, ALL the source files are in src/, and ALL the header files are in include/. This suggests the STK is a monolithic library, but that's not really the case…
>
> Most use cases of STK involve a handful of its classes, the user cherry-picks them before compile time. We very rarely need every one of the 104 classes in our project.
>
> If I want to use, say, PRCRev, the only classes I need to include are the ones it inherits from:
> PRCRev
> Effect
> Delay
> Filter
> and Stk
>
> that's 5 classes out of 104
>
> Another example: if I want to use, say, Wurley, I only need 12 classes. Out of the 104 classes.
>
> It makes sense for frameworks like Pure Data or SuperCollider to build every source file, given that the user may use of any one of its constituent classes at runtime. But the STK is for programmers, and programmers make decisions, before compile time, about which classes will and will not be used .
>
> The STK's directory structure needs to facilitate that. We should make it easier for a STK user to cherry-pick the classes he or she will actually use. Additionally, this would give users a much clearer picture of how the library is really structured.
>
> I'd say a good directory structure reflects the loose coupling pattern in place, grouping classes by functionality. I propose the following:
>
>
> _base/
> Abstract base classes (e.g. Effect, Delay, Filter)
>
> _filters/
> All the classes that filter/effect audio (e.g. TwoPole, PRCVerb, etc.)
>
> _synths/
> All the classes that generate audio (e.g. Guitar, Mandolin, Twang, etc.)
>
> _rawwaves/
> All the raw wave files
>
>
> audio_layer/
> RtAudio
> RtAudio
> RtError
> as well as the contents of src/include/:
> asio, dsound, soundcard, etc.
>
> File_IO/
> FileRead
> FileLoop
> FileWrite
> WvIn
> WvOut
> FileWvIn
> FileWvOut
>
> System_IO/
> RtWvIn
> RtWvOut
> RtWvIn
>
> Multithreading/
> All the multithreading classes:
> Thread
> Mutex
>
> Networking/
> All the networking classes:
> UdpSocket
> Socket
> TcpClient
> TcpServer
>
> MIDI/
> MidiFileIn
> RtMidi
> makemidi.c
>
> Misc/
> makefun.c
> makewavs.c
> sine.c
>
>
> This proposal for a new directory structure is, of course, open to amendments, additions, and fixes.
>
> So, these are the motivations for reorganising the directory structure, and I hope I've suggested a clean way in which it can be done.
>
> Looking forward to your thoughts.
>
> Cheers
>
> Ariel
>
>
> _______________________________________________
> Stk mailing list
> Stk at ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/stk
>
>