summaryrefslogtreecommitdiff
path: root/src/libs/sig
AgeCommit message (Collapse)Author
2021-02-14*: split rototiller.[ch] into lib and mainVito Caputo
This is a first approximation of separating the core modules and threaded rendering from the cli-centric rototiller program and its sdl+drm video backends. Unfortunately this seemed to require switching over to libtool archives (.la) to permit consolidating the per-lib and per-module .a files into the librototiller.a and linking just with librototiller.a to depend on the aggregate of libs+modules+librototiller-glue in a simple fashion. If an alternative to .la comes up I will switch over to it, using libtool really slows down the build process. Those are implementation/build system details though. What's important in these changes is establishing something resembling a librototiller API boundary, enabling creating alternative frontends which vendor this tree as a submodule and link just to librototiller.{la,a} for all the modules+threaded rendering of them, while providing their own fb_ops_t for outputting into, and their own settings applicators for driving the modules setup.
2020-02-10libs/sig: triangle wave; sig_ops_tri / sig_new_tri()Vito Caputo
Added a triangle wave
2020-02-04libs/sig: square wave; sig_ops_sqr / sig_new_sqr()Vito Caputo
This builds minimally upon the existing sine wave code, just use the sign to drive the signal high or low. Wikipedia shows a third state for 0 values, but that's for a -1..+1 signal. I'm producing all 0-1 signals as it's more convenient for this application, but it seems like it would be awkward to return .5f for the 0 case. So 0 is being treated as just another positive value; high.
2020-02-04libs/sig: add sig_new_$op wrappersVito Caputo
Provides improved ergonomics when using the bulitin ops, and much appreciated arity and type checking.
2020-02-03libs/sig: add sig_ref()Vito Caputo
Added some rudimentary refcounting so sig_t's can be readily shared by multiple sig_t's.
2020-02-03libs/sig: remove ticks_ms modulo in sig_ops_sinVito Caputo
Seems broken, fix it correctly later.
2020-02-03libs/sig: fix sig_ops_sin hz floor checkVito Caputo
off by one order of magnitude
2020-02-03libs/sig: add sig_ops_invVito Caputo
map 0-1 inputs to their inverse 1-0
2020-02-03libs/sig: s/sig_ops_inv/sig_ops_neg/gVito Caputo
Rename inv->neg, preparation for a new sig_ops_inv for inverting 0..1 to 1..0
2020-02-03libs/sig: add sig_ops_divVito Caputo
Included a little hack to defend against divide by zero, seems reasonable given the intended use cases.
2020-02-03libs/sig: add sig_ops_{add,sub}Vito Caputo
2020-02-03libs/sig: add sig_ops_expand convenienceVito Caputo
This is a specialized version of sig_ops_scale which assumes a min..max range of -1..+1 nvidia register combiners docs describe this operation as "expand normal", and they have several variants, but I don't want to go too crazy here right now. Plain expand it is.
2020-02-03libs/sig: add sig_ops_scale w/test exampleVito Caputo
This assumes the input value is always 0-1, but may be used to produce values in any signed range, mapped linearly to the input.
2020-02-03libs/sig: add sig_ops_inv for additive inverseVito Caputo
aka negation
2020-02-03libs/sig: fixup sig_ops_sin to stay within 0-1Vito Caputo
The whole idea was to produce values 0-1, except of course sig_ops_{mult,const} where one could deliberately get out of these bounds. Everything else should stay within 0-1 as it makes everything much more composable.
2020-02-03libs/sig: add sig_ops_{max,min}Vito Caputo
Supply two sig_t *'s: a, b
2020-02-03libs/sig: add sig_ops_clampVito Caputo
Supply three sig_t *'s: value, min, max
2020-02-03libs/sig: add ops_{abs,ceil,floor,pow,round}Vito Caputo
Added a simple test exercising pow and round
2020-02-03libs/sig: consideration for sig_t.ctxt alignmentVito Caputo
The flexible array of void *'s would just align to a pointer, which may not be safe for all members of whatever gets shoved in here. In an effort to make it more robust, make it an array of a junk drawer union of types.
2020-02-03libs/sig: update comment for ops_lerp_initVito Caputo
Comment was vestigial from ops_mult.c which ops_lerp.c was derived from.
2020-02-03libs/sig: add sig_ops_rand random generatorVito Caputo
(Ab)uses rand_r by feeding ticks_ms as seedp for pseudo-random numbers deterministically derived from ticks_ms.
2020-02-03libs/sig: remove math.h include from ops_const.cVito Caputo
2020-02-03libs/sig: cosmetic rearrangementVito Caputo
Make sig_ops_t.destroy functions consistently after init, no functional changes.
2020-02-03libs/sig: add sig_ops_lerp linear interpoplationVito Caputo
This takes three signals; a, b, and t t controls the weight interpolating between a and b, they all key off the same time ticks_ms.
2020-02-03libs/sig: convert ops_sin_ctxt_t.hz to a sig_t *Vito Caputo
Now hz can vary with time as well...
2020-02-03libs/sig: intrduce sig_ops_constVito Caputo
The simplest of signals: a constant value. The immediate need for this is to convert ops_sin_ctxt_t.hz to another sig_t enabling varying hz with time, while still being able to have a fixed hz as well.
2020-02-03libs/sig: introduce a signal generator abstractionVito Caputo
This adds a small framework of sorts for creating and composing signal generators. Two generators are implemented at this time; sig_ops_sin and sig_ops_mult sig_ops_sin accepts a hz variable and will produce a sine wave of that frequency. sig_ops_mult accepts two sig_t generators and multiplies their outputs Callers may construct their own sig_ops_t ops structs and supply them to sig_new(), but it's expected that libs/sig will grow a collection of commonly used generators which can then be used by simply passing their sig_ops_$foo to sig_new(). See the test code at the bottom of libs/sig/sig.c for some contrived sample usage. Note by composing multiple sig_ops_sin generators with a sig_ops_mult generator, one can already easily construct a synth-like LFO generator. Some obvious todos are to add triangle/sawtooth/square wave generators. More compositional generators may be interesting as well, like additive and subtractive for example. Those will need to implement clipping, as it's expected that the generators *always* stay within unity (0-1). No modules use this yet, but I expect to wire this up to rtv for driving knobs.
© All Rights Reserved