orastron/brickworks
2
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 10 Wiki Activity

TODO now lives in a better place + fix typos

Browse Source
This commit is contained in:
Stefano D'Angelo 2023-09-27 17:44:59 +02:00
parent dbee544059
commit 7b968161ec
3 changed files with 3 additions and 85 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

82
TODO
View File

@ -1,82 +0,0 @@
1.0.0
-----
* clearly specify that state is tied to a particular set of coeffs (1:N)
* state that sample rate is finite and > 0
* state that audio cannot be inf (also in reset)
* state that you need different output buffers to reset
* state that mem_set() can/must be called on uninitialized state (before reset_state)
build system:
* single header generation (vs modules in bwp... to think about)?
post 1.0.0
----------
code:
* get() parameters?
* blep etc in a module?
* optimize triangle generation for constant pulse width
* compute bit depth reduction only when input changes? (state, option?)
* avoid "force" in coeffs update by using inline functions?
* csch for bw_peak bandwidth -> Q, inv sqrt ls2 hs2
* separate tests and examples?
* define common midi CCs for examples
* MEM_REQ_ROUGH() macro?
* web examples: need to export memset?
* check unused param warning visual studio
* float -> double, etc. ?
* bw_buf_copy (to be used in bw_slew_lim)?
* src post filt?
* web examples construction/destruction
* web effect mono->stereo and stereo->mono inputs? or display "input needs to be n channels"?
* fix vst3 mapped values (visible in Ableton Live) and short names
* polish examples (ranges, etc.)
* dump data structures (see note queue) and indicate error precisely
* process (multi) no update
* examples cpu usage
* bw_math: review types in implementation
* way to detect extern "C"? perhaps hidden "trap" preprocessor definition?
* any chance to avoid casts in C for const X * const * input arguments?
* heavy debug (e.g. also stripping restrict) vs light debug vs release vs optimized makefile rules
* smaller optimized modules (e.g., simple one pole)
* one pole, slew lim, maybe others: process const input? (return also if const out)
* pan process with no out: should just reset coeffs?
* float in [0,1] or [-1,1] for velocity, pitch bend, mod wheel in examples
* bw_satur gain compensation, divide by actual gain (derivative) mode? what about around flat line? bw_clip?
* gain compensation in distortions?
* sr-dependent vs cr-dependent coeffs? see synth poly example and pan case
* modulation vs process (multi) no update (post 1.0.0)???
* reset_state_multi allow NULL input?
* process allow NULL output?
* #if __cplusplus >= 201103L ? - see https://stackoverflow.com/questions/5047971/how-do-i-check-for-c11-support
* get current compression level, knee
* src inside distortions? w/ control from outside?
* make all outs nullable?
* make all reset state outs nullable (svf, phase_gen, ...)?
* ring mod fx module?
* bitcrusher module?
* return output std::array rather than have it as input argument?
* common smoothing policy (as control rate as possible?) - smoothing control?
* max_delay -> set sample rate? see reverb
* mem req -> return value of set sample rate? or sample rate argument of mem req?
* c++ get coeffs/state? or public? src nIn/OutSamples case (array vs single value pre 1.0.0), delay read/write, process1? process single?
* bw_comb: should also modulate feedback?
* bw_comb: integer target delay values?
* are we sure about inlining everything?
* reset style is not enough when you have feedbacks... (see reverb)
* IMPLEMENTATION/DECL/DEF prepocessor defs, maybe if DECL/DEF is defined then IMPLEMENTATION is needed to get implementation, etc.
* actually assert no buffer overlap
build system:
* make makefiles handle paths with spaces etc
* can run su on windows? (system-wide install)
* make autodependencies (.d?) - https://make.mad-scientist.net/papers/advanced-auto-dependency-generation/
* make from... directories
* recursive make?
* make hashdeps (https://github.com/olipratt/hashdeps)?
* VC, XCode, etc project files?
* single header(s)
* cross compile (rpi etc.)
* better use of xcodegen (see xcode warnings) and/or consider tuist (https://tuist.io/), bazel (https://bazel.build/), pants (https://www.pantsbuild.org/), buck (https://buck2.build/), please (https://please.build/index.html) for mobile apps
* homogenize android and ios common code (e.g., same index)

4
include/bw_buf.h
View File

@ -39,8 +39,8 @@
* <li>Added overloaded C++ functions taking C-style arrays as * <li>Added overloaded C++ functions taking C-style arrays as
* arguments.</li> * arguments.</li>
* <li>Removed usage of reserved identifiers.</li> * <li>Removed usage of reserved identifiers.</li>
* <li>Now enforcing that buffers are never <code>NULL</code> in * <li>Now checking that buffers are never <code>NULL</code> and that
* debugging code.</li> * output buffers are different in debugging code.</li>
* </ul> * </ul>
* </li> * </li>
* <li>Version <strong>0.6.0</strong>: * <li>Version <strong>0.6.0</strong>:

2
include/bw_common.h
View File

@ -170,7 +170,7 @@
* *
* Otherwise, `BW_ASSERT` and `BW_ASSERT_DEEP` can either be provided by you, * Otherwise, `BW_ASSERT` and `BW_ASSERT_DEEP` can either be provided by you,
* otherwise `BW_ASSERT` is defined as `assert` (`assert.h` is `#include`d * otherwise `BW_ASSERT` is defined as `assert` (`assert.h` is `#include`d
* and `BW_NO_STDLIB` must not be defined &mdash; please mid that `assert.h` * and `BW_NO_STDLIB` must not be defined &mdash; please mind that `assert.h`
* is still influenced by `NDEBUG`), and `BW_ASSERT_DEEP` is defined as * is still influenced by `NDEBUG`), and `BW_ASSERT_DEEP` is defined as
* `BW_ASSERT`. * `BW_ASSERT`.
* *