FunctionLib is conceived to be a library of mathematical functions with a standardized interface, and consists of a number of functions:

• Each function provides a method y=f(x) mapping a value x in the normalized range [0,1]? into value y in the range [0,1]?
• The function f might require an arbitrary number of parameters (e.g. curvature (steepness) of the function, center offset (compression, expansion of the function curve...) )
  
• The function f need to define how to deal with input values outside the range [0,1]?. If possible this should be done by extrapolating the function. Other possibilities could be considered (e.g. clip, wrap, reflect...)
  

The method of a FunctionLib function is defined thus:

double myfunction(double x, short numparameters, double *parameters)

x:					The input value to be mapped.
numparameters:					The number of parameters passed to and defining the function. (optional)
parameters:					An array of parameters.
					The function returns the value y

FunctionLib can be used for a number of tasks in Jamoma:

1. Mapping

The most straightforward example for using FunctionLib is implemented in jcom.map, which is  a kind of  Max scale object, with access to all available FunctionLib functions

Mapping functions (UnitLib ?) would be readily available by first linearly mapping the input range [a,b]? onto [0,1]? and then call a FunctionLib function, and then scaling from [0,1]? to [c,d]?

Syntax :

Each one of the parameters can  be accessed via an attribute :
InputMin? (a)
InputMax? (b)
OutputMin? (c)
OutputMax? (d)

Extra parameters can be available, depending on the functions
e.g. : curvature, center...
addressed via setParameter parameter_name value

List support :

An interesting perspective could be to support lists in the mappings.
The question then is : how do we set different ranges and functions for each member of the list ?
Trond suggests that we send arrays of values for each parameter....

2. As part of RampLib:

FunctionLib would provide access to a number of different curves to use for ramping. RampLib can be thought of as a combination of two components:

• A scheduling method deciding when to generate new values during a ramp, producing a stream of values x progressing linearly from 0. to 1. over the duration of the ramp.
• A function chosen in the FunctionLib
  
• A mapping method to map values from the FunctionLib from the range [0.,1.]? onto the range [c,d]?. (by default, [c,d]? coincide with the object (i.e. jcom.parameter, etc... range) -> is that related to the UnitLib, by any chance ?
  

Any scheduling method can be combined with any ramping method, and specified by the @ramp.function attribute: @ramp.function rampFunction and by the @ramp.drive attribute : @ramp.drive scheduler

Some possible @ramp.function
- linear
- tanh
- cosine
- exponential
- random (diverse distributions ?)
- lookup table ?

Some possible  @ramp.drive
- scheduler,
- queue.
- dsp
- bang (like bline)
- event ? (event driven... depending on what comes in jcom.in)
- LFO ?

The various combinations would be implemented by means of RampLib coupling a pointer to a drive function with a pointer to a FunctionLib mapping function.

3. Library of stochastic functions

By mapping a uniform random distribution in the range [0,1> onto the range [c,d]? using FunctionLib a single random generator could be used to create a number of stochastic distributions.

4. LFO oscillators

A number of signal and control rate LFO oscillators could be implemented by passing a phasor~ or triangle~-like signal to a mapping function, or by using Functionib to calculate lookup tables for processing efficiency.



FunctionLib should be implemented as part of the Jamoma core.

Two more things from Tim

1. If the FunctionLib is implemented in the framework, then the functions will be available everywhere.

2. All of the functions, if possible, should have a method called 'lookup' which will not calculate the value but instead fetch a value from a pre-calculated lookup table. In most cases (especially where trig functions are called) this will be *a lot* faster -- critical for use in ramping.