1.0.0 ----- in progress: * add initial state (x0) to reset state of all modules * check assumptions w.r.t. usage of math functions * empty functions etc. to keep consistency and forward compatibility * format declarations in a more readable way code: * IMPLEMENTATION prepocessor def??? finally: * debugging - also check outputs different (incl bw_buf) * check all examples again * 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 * thank scientific paper authors * change config.h in examples version 1.0.0 * "Templates must have C++ linkage"? 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? 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)