TODO now lives in a better place + fix typos
This commit is contained in:
parent
dbee544059
commit
7b968161ec
82
TODO
82
TODO
@ -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)
|
||||
@ -39,8 +39,8 @@
|
||||
* <li>Added overloaded C++ functions taking C-style arrays as
|
||||
* arguments.</li>
|
||||
* <li>Removed usage of reserved identifiers.</li>
|
||||
* <li>Now enforcing that buffers are never <code>NULL</code> in
|
||||
* debugging code.</li>
|
||||
* <li>Now checking that buffers are never <code>NULL</code> and that
|
||||
* output buffers are different in debugging code.</li>
|
||||
* </ul>
|
||||
* </li>
|
||||
* <li>Version <strong>0.6.0</strong>:
|
||||
|
||||
@ -170,7 +170,7 @@
|
||||
*
|
||||
* 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
|
||||
* and `BW_NO_STDLIB` must not be defined — please mid that `assert.h`
|
||||
* and `BW_NO_STDLIB` must not be defined — please mind that `assert.h`
|
||||
* is still influenced by `NDEBUG`), and `BW_ASSERT_DEEP` is defined as
|
||||
* `BW_ASSERT`.
|
||||
*
|
||||
|
||||
Loading…
Reference in New Issue
Block a user