From 649ce74aafd6523dc85890e2b5c906928b61b1a1 Mon Sep 17 00:00:00 2001 From: Weird Constructor Date: Tue, 19 Jul 2022 06:10:24 +0200 Subject: [PATCH] more notes about the quality guideline --- src/dsp/mod.rs | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/src/dsp/mod.rs b/src/dsp/mod.rs index 005f3c7..a4f996a 100644 --- a/src/dsp/mod.rs +++ b/src/dsp/mod.rs @@ -17,6 +17,7 @@ When adding a new node to HexoDSP, I recommend working through the following che - [ ] Parameter fine tuning - [ ] DSP tests for all (relevant) params - [ ] Ensure Documentation is properly formatted for the GUI +- [ ] Format the source using `cargo fmt` - [ ] Add CHANGELOG.md entry in HexoSynth - [ ] Add CHANGELOG.md entry in HexoDSP - [ ] Add table entry in README.md in HexoSynth @@ -30,13 +31,17 @@ until you get the hang of all the things involved to make it compile in the firs **Be aware that new DSP nodes need to meet these quality guidelines to be included:** -- Clean Rust code that I can understand and maintain. +- Clean Rust code that I can understand and maintain. You can use `cargo fmt` (rustfmt) to +format the code. - Does not drag in huge dependency trees. One rationale here is, that I don't want the sound of a HexoSynth patch to change (significantly) because some upstream crate decided to change their DSP code. To have optimal control over this, I would love to have all the DSP code contained in HexoDSP. Make sure to link the repository the code comes -from though. +from though. If you add dependencies for your DSP node, make sure that it's +characteristics are properly covered by the automated tests. So that problems become +visible in case upstream breaks or changes it's DSP code. If DSP code changes just slightly, +the test cases of course need to be changed accordingly. - Come with automated smoke tests like all the other nodes, most test signal min/max/rms over time, as well as the frequency spectrum where applicable.