Devel

From Clam

This is the CLAM development wiki.

Please, prepend 'Devel/' to any development pages you create here.

Some development pages are still at the old CLAM development wiki.

Contents

Subversion access

Subversion tree contains CLAM libs and applications: NetworkEditor, Annotator, SMSTools and Voice2MIDI.

  • Open and read-only
$ svn co https://iua-share.upf.edu/svn/clam/trunk clam

Getting involved

To get involved with CLAM development:

HOWTO's

Tasks

Prepare and apply a patch

We only give write access to the repository to developers with experience with clam development. But this not a problem since you can always send a patch to the devel-list, and clam-devs will take care of it (and we use to be quick).

We like receiving patches very much. Please do it even for very small things like improving the INSTALL file, or grammar corrections in the code comments. (So imagine how we like receiving bug-fixes!). Luckily, working with patches in subversion is very easy:

  • How to create a patch with your local modifications?
Change dir to the root of your svn tree (under CLAM/ and NetworkEditor/, etc.) and do
$ svn diff > good-description.patch
  • How to apply a patch (that maybe somebody posted to the list)?
Change dir to the root of your svn tree and do
$ patch -p0 < the.patch

We prefer the patches being sent to the clam-devel mailing list. The issue tracker will be used when patches can not be applied (or discarded) immediately and need to remain on hold for some time.

Pass the automatic tests

Checkout the clam test-data repository:

$ svn co https://iua-share.upf.edu/svn/clam-test-data/trunk clam-test-data


Change dir to CLAM/test and compile with scons providing the following options (no installation step is needed):

  • clam_prefix --which is the prefix where you installed clam. /usr/local by default
  • test_data_path --the path to the clam-test-data sandbox (local copy of the repository).

For example:

$ scons clam_prefix=~/local test_data_path=~/clam-test-data

Then execute unit and functional tests:

$ ./UnitTests/UnitTests
$ ./FunctionalTests/FunctionalTests


Hot Spots

Things that core developers are eager to address but still not being refined in small tasks. Of course they need discussion.

  • Protocol allowing processings to let the network decide its (audio) port size.
  • Parameter propagation through the data-flow
  • Recursive networks
  • Static network scheduling (Maybe based on an recursive analysis starting from sinks)
  • Ease Processing writing: not make a config attribute mandatory.
  • Unify Do() return semantics. One solution is do it void Do()
  • Spectrum refactoring: one class per representation (complex, mag-phase, ...)