1
2Contributing
3============
4
5The qm-dsp library is maintained in a Github repository at
6https://github.com/c4dm/qm-dsp.
7
8
9Reporting bugs
10--------------
11
12Please use Github issues for bug reports. Try to make them as specific
13as possible. For example, describe an input that triggers some
14particular behaviour, and tell us how that behaviour differs from what
15you expected.
16
17If your bug can be reproduced by processing an audio file using one of
18the QM Vamp Plugins (https://github.com/c4dm/qm-vamp-plugins), which
19are built using this library, that might be a good way to illustrate
20the problem.
21
22
23Pull requests
24-------------
25
26We're happy to see pull requests, and can pull them directly in some
27circumstances.
28
29 * Please make sure your change compiles without warnings and passes
30   the existing tests.
31
32 * Please follow the code style guidelines (see below).
33
34 * Please make it as easy as possible to verify the behaviour of the
35   pull request, for example by adding a new test in the `tests`
36   directory. This library has only limited test coverage, but we
37   would like to expand it, and prefer not to make changes unless they
38   are backed by tests.
39
40 * Please provide your changes under terms which permit Queen Mary
41   University of London to relicense the code for commercial
42   purposes. The qm-dsp library as a whole is provided under the GPL,
43   but QM also make commercial licences available separately, and
44   cannot accept any pull request whose copyright status would prevent
45   that. In practice, this means any non-trivial change not
46   originating from QM must be explicitly licensed using a BSD-like
47   licence text, either in the source file itself or in an
48   accompanying file. See `thread/BlockAllocator.h` for an example of
49   typical language.
50
51Please note also that fixes which change the behaviour of the existing
52QM Vamp Plugins will need particularly close scrutiny - these are
53reasonably widely used and, even where they have defects, changes may
54cause problems for users and will at least need to be documented with
55the plugins. For this reason it may take some time for such changes to
56be reviewed or integrated.
57
58
59Code style
60----------
61
62 * C++ code must compile with the C++98 standard, except for the unit
63   tests which are C++14
64
65 * Classes are named `LikeThis` - functions, methods, and local
66   variables `likeThis` - class member variables `m_likeThis`
67
68 * Indentation is four spaces at a time (no tabs)
69
70 * The opening brace for a block goes at the end of the line, except
71   at the start of a function or class definition where it gets a line
72   of its own
73
74 * Please use braces around any conditional or loop block that is not
75   on the same line as the test
76
77 * Please keep lines to no more than 80 characters in length
78
79 * Avoid using unsigned int types, unless doing bit manipulation (see
80   http://soundsoftware.ac.uk/c-pitfall-unsigned.html for rationale)
81
82