summaryrefslogtreecommitdiff
path: root/src/libs/sig
AgeCommit message (Collapse)Author
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