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