Status: Refactoring for the Plug-ins (I like to move it, move it)

[Gabriel M. Beddingfield]

Hi guys,

Here's where things are currently at with Composite:

1. Reorganizing Sampler and Instrument code for use
in plugins. Will also reorganize and rename the
Hydrogen and AudioEngine classes.

[Note: When the plugins are done, you'll be able
to use Composite/Hydrogen drum kits directly in
applications like Rosegarden.]

2. Unit tests for Tritium have been reinstated and
can be run with 'ctest'. This has helped me
avoid making regressions at least twice.

3. Several key classes are being converted to a
d-pointer (opaque pointer) to try and get a
stable ABI for libTritium.

4. CMake build system is complete, but can use a
little refinement. It is able to find libraries
on Windows, but chokes on a technicality.

5. The major code rearrangement is done (moving
directories, renaming files, etc.).

That's the summary. If anyone wants details... keep
reading.

1. SAMPLER REORGANIZATION
-------------------------

My vision is for the Sampler class to manage all of the
Instrument instances. Inside of Sampler::process(),
each instrument will also have Instrument::process()
called, and they will render the notes. This way, the
instruments themselves handle envelopes, sample
rendering, what is currently playing (and what is not),
etc.

Currently, all of the Instrument's are owned by the
Song class. Moving them out of Song and into the
Sampler means that I also have to refactor the
serialization code (how a song file or drum kit gets
opened and saved).

2. UNIT TESTS
-------------

Last spring, when I started the Transport redesign, I
also instituted several test programs, to test that
each class is working "as expected." These are now
fully working. You can run each one directly (located
in src/Tritium/test) or in your build directory you can
run them all with:

$ ctest

If you already have `jackd` running, then the tests
will run a little faster. Note that t_SeqScript will
always fail. If you run it directly it will tell you
why:

$ ./src/Tritium/test/t_SeqScript
/mnt/gabriel/gabriel/code/composite/src/Tritium/test/t_SeqScript.cpp(291): error in "_060_consumed_pass_2": This module is needing more tests... so it fails.

We still need lots more tests to be written... and not
just for SeqScript, but (ideally) every class in
Tritium.

Note that Composite makes liberal use of Singleton
objects.[1] While making it easier to write a
monolithic application, it makes it hard to write
libraries and unit tests.[2] I'm slowly
un-singleton-ing as much as I can (but decided to keep
the Logger class as a singleton).

3. D-POINTERS
-------------

Since libTritium will be a shared library, I'm trying
to get binary compatibility stable ASAP. Wherever
possible, I'm utilizing a d-pointer[3]. This means
that I can change implementation details (like how
things are stored internally... whether std::vector<>
or std::deque<> or a custom linked list), but
externally a call to get_ADSR() will act the same.

Further, after linking composite-gui to libTritium... I
can after-the-fact do things like add non-virtual
functions to a class, and totally change the classes
implementation -- and I don't even have to re-compile
composite-gui.

4. CMAKE STATUS
---------------

CMake is working out very well, and I've got it
configured to where it's possible to find libraries
(like JACK) on Windows.

However, it currently still fails on Windows because I
instruct it to link against things like
${LibTar_LIBRARIES}... but since these weren't found,
it issues an error. However, we don't /need/ libtar,
because we're using libarchive. So, this needs to be
cleaned up.

Also, I'm wanting/needing to look into CPack, and what
it can do for us and how to set it up.

The target 'make dist' is currently not set up, either.

5. CODE REARRANGEMENT
---------------------

I renamed stuff like this:

jack_output.cpp ==> JackOutput.cpp
JackOutput.h ==> JackOutput.hpp

I also moved everything into a src/ directory and put
composite-gui and Tritium (the library) side-by-side.
I'm pretty much done with this... with some exceptions.
For example, all of the driver-specific stuff needs to
be moved out of src/Tritium/Tritium/IO (the API
headers) and moved to src/Tritium/src/IO. Doing this
requires a more capable driver/port abstraction,
though.[4]

For what it's worth: Git handles renames really well on
renames and stuff. I was even able to cherry-pick a
commit from the current Hydrogen... and it detected all
the renames and applied the patch correctly without any
intervention on my part.

Peace,
Gabriel

[1] http://en.wikipedia.org/wiki/Singleton_pattern
[2] Hyslop and Sutter, "Once is Not Enough", Dr. Dobb's
Journal March 1, 2003 (http://www.ddj.com/cpp/184401625)
[3] http://en.wikipedia.org/wiki/Opaque_pointer
[4] Lots of stuff adds special features if the Audio
driver is JACK. So, even some GUI code includes
the <Tritium/IO/JackOutput.hpp> header.