As a computer music composer, I found the transition from domain-specific languages/environments such as SuperCollider, MaxMSP, or PD into C++ audio programming tremendously challenging. In retrospect, the cause of this struggle is quite clear; programming audio well in C++ requires a firm background in both mathematics and computer science. A typical composer may have neither of these. It occurs to me also that the situation is true in reverse; a mathematician or computer scientist may not have enough background in music signal processing or the needs/desires of such a community.
Pedal is my response to this predicament. It favors clarity, modularity, and computational performance in that order.
Clarity: All classes are named clearly, follow a consistent design pattern, and forego base classes. Each document is treated as a lesson and thoroughly documented. Documentation includes not only what is being done and why, but also give context of the algorithm in recent history, how these classes are typically used, and where to look for more information. Pedal is verbose. The variable name has explicit and full meaning. Naming is consistent within class types. If two classes have identical methods (which occurs frequently as inheritance was omitted) they should be named identically.
Modularity: Pedal is designed in C++ to compile for PC, Macintosh, and Linux. The omission of base classes makes taking classes from the library trivial. Interdependence within Pedal is kept to a minimum to support this. Pedal also uses as few external libraries as possible, and when used the most portable option is chosen if performance is not dramatically reduced.
Performance: Clear code need not be slow, it just takes longer to write. We at all times choose the best method that will not break portability. In many cases, there are multiple methods that vary in accuracy and computational cost. These methods are contained in separate classes. The computational workload of a class is noted in the document when high. Hopefully real performance results and comparisons to other libraries will be available in the future.
Work on pedal is ongoing but will hopefully be available soon.
Link to repository:
https://github.com/aaronaanderson/Pedal
Pedal is my response to this predicament. It favors clarity, modularity, and computational performance in that order.
Clarity: All classes are named clearly, follow a consistent design pattern, and forego base classes. Each document is treated as a lesson and thoroughly documented. Documentation includes not only what is being done and why, but also give context of the algorithm in recent history, how these classes are typically used, and where to look for more information. Pedal is verbose. The variable name has explicit and full meaning. Naming is consistent within class types. If two classes have identical methods (which occurs frequently as inheritance was omitted) they should be named identically.
Modularity: Pedal is designed in C++ to compile for PC, Macintosh, and Linux. The omission of base classes makes taking classes from the library trivial. Interdependence within Pedal is kept to a minimum to support this. Pedal also uses as few external libraries as possible, and when used the most portable option is chosen if performance is not dramatically reduced.
Performance: Clear code need not be slow, it just takes longer to write. We at all times choose the best method that will not break portability. In many cases, there are multiple methods that vary in accuracy and computational cost. These methods are contained in separate classes. The computational workload of a class is noted in the document when high. Hopefully real performance results and comparisons to other libraries will be available in the future.
Work on pedal is ongoing but will hopefully be available soon.
Link to repository:
https://github.com/aaronaanderson/Pedal