1.0.0 ----- code: * debugging - also check outputs different (incl bw_buf) * check all examples again * osc post filter (and one pole init, slew rate, etc.) val from input? set state instead? * audio rate optional pulse width/slope inputs? * should rather use backward Euler in bw_onepole? * one pole process const input? (return also if const out) * empty functions etc. to keep consistency and forward compatibility? * float in [-1,1] for velocity, pitch bend, mod wheel * should clip slope in triangle? * common smoothing policy (as control rate as possible?) - smoothing control? * svf bandpass out polarity too confusing (inverted in mm2)? * pan process with no out: should just reset coeffs? * get_y_z1, common strategy? * bw_satur gain compensation to divide by actual gain (derivative) rather than gain parameter? * cite papers, thank authors * add initial state (x0) to reset state of lp1, ap1, mm1, hs1, ls1, others? all? * bw_comb: should also modulate feedback? * bw_comb: integer target delay values? * bw_svf/lp1 automatically limited (max) prewarp frequency to avoid instability? * prewarp control in all derived filtering modules * src inside distortions? w/ control from outside? * bw_fuzz gain compensation? * make gain of distortions homogeneous? * max_delay -> set sample rate? see reverb * update state ctrl -> process ctrl? * mem req -> return value of set sample rate? * peak gain + Q ??? * sr_reduce reset_coeffs? update_coeffs? process_multi? * allow nullptr in C++ wrappers where process_multi arg can be NULL * better src filter * c++ get coeffs/state? or public? src nIn/OutSamples case (array vs single value), delay read/write, process1? process single? * check unititialized warnings (check fxpp_comp in particular vs fxpp_satur) * clearly specify that state is tied to a particular set of coeffs (1:N) * modulation vs process (multi) no update (post 1.0.0)??? * check assumptions w.r.t. usage of math functions * sample rate-constant coeffs? (pan case) * sr-dependent vs cr-dependent coeffs? see synth poly example * src x != y? build system: * single header generation (vs modules in bwp... to think about) post 1.0.0 ---------- code: * 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) 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)