
Synthesizer.Inference.Reader.Process  Portability  requires multiparameter type classes (OccasionallyScalar)  Stability  provisional  Maintainer  synthesizer@henningthielemann.de 



Description 
Lightweight sample parameter inference which will fit most needs.
We only do "poor man's inference", only for sample rates.
The sample rate will be provided in a Reader monad.
We almost do not need monad functionality
but only Control.Applicative functionality.
In contrast to the runtime inference approach,
we have the static guarantee that the sample rate is fixed
before passing a signal to the outside world.


Synopsis 



Documentation 


This wraps a function which computes a sample rate dependent result.
Sample rate tells how many values per unit are stored
for representation of a signal.
 Constructors   Instances  


run :: t' > T t t' a > (t', a)  Source 



::   => T t t' a  process that provides a result
 > a > T t t' b  function that can reuse that result as much as it wants
 > T t t' b   Reuse a result several times without recomputing.
With a simple let you can reuse a result
but it must be recomputed due to the dependency on the sample rate.



injectParam :: (a > T t t' b) > T t t' (a > b)  Source 


extractParam :: T t t' (a > b) > a > T t t' b  Source 


convertTimeParam :: (t' > t' > t) > t' > (t > a) > T t t' a  Source 

The first argument will be a function like InferenceReader.Signal.toTimeScalar.
If you use this function instead of InferenceReader.Signal.toTimeScalar directly,
the type t can be automatically infered.



:: Functor f   => f (a > a)  process chain that shall be looped
 > f a   Create a loop (feedback) from one node to another one.
That is, compute the fix point of a process iteration.




This corresponds to Control.Applicative.pure



This corresponds to <*>



Instead of mixMulti $:: map f xs
the caller should write mixMulti $: mapM f xs
in order to save the user from learning another infix operator.











Our signal processors have types like f (a > b > c).
They could also have the type a > b > f c
or f a > f b > f c.
We did not choose the last variant for reduction of redundancy in type signatures,
and we did not choose the second variant for easy composition of processors.
However the forms are freely convertible,
and if you prefer the last one because you do not want to sprinkle '($:)' in your code,
then you may want to convert the processors using the following functions,
that can be defined purely in the Applicative class.






liftP4 :: Applicative f => f (a > b > c > d > e) > f a > f b > f c > f d > f e  Source 


Produced by Haddock version 2.3.0 