FunDSP

Audio Processing and Synthesis Library for Rust

FunDSP is an audio DSP (digital signal processing) library for audio processing and synthesis.

FunDSP features a powerful inline graph notation for describing audio processing networks. The notation taps into composable, zero-cost abstractions that express the structure of audio networks as Rust types.

Another innovative feature of FunDSP is its signal flow system, which can determine analytic frequency responses for any linear network.

FunDSP comes with a combinator environment containing a suite of audio components, math and utility functions and procedural generation tools.

Uses

• Audio processing and synthesis for games and applications
• Education
• Music making
• Sound hacking and audio golfing
• Prototyping of DSP algorithms

Rust Audio Discord

To discuss FunDSP and other topics, come hang out with us at the Rust Audio Discord.

Related Projects

bevy_fundsp integrates FunDSP into the Bevy game engine.

midi_fundsp enables the easy creation of live synthesizer software using FunDSP for synthesis.

Graph Notation

FunDSP Composable Graph Notation expresses audio networks in algebraic form, using graph operators. It was developed together with the functional environment to minimize the number of typed characters needed to accomplish common audio tasks.

Many common algorithms can be expressed in a natural form conducive to understanding. For example, an FM oscillator can be written simply as:

sine_hz(f) * f * m + f >> sine()

The above expression defines an audio graph that is compiled into a stack allocated, inlined form using the powerful generic abstractions built into Rust. Connectivity errors are detected during compilation, saving development time.

Audio DSP Becomes a First-Class Citizen

With no macros needed, the FunDSP graph notation integrates audio DSP tightly into the Rust programming language as a first-class citizen. Native Rust operator precedences work in harmony with the notation, minimizing the number of parentheses needed.

FunDSP graph expressions offer even more economy in being generic over channel arities, which are encoded at the type level. A mono network can be expressed as a stereo network simply by replacing its mono generators and filters with stereo ones, the graph notation remaining the same.

Basics

Component Systems

There are two parallel component systems: the static AudioNode and the dynamic AudioUnit.

The main property of a component in either system is that it is a processing node in a graph with a specific number of input and output connections, called its arity. Audio and control signals flow through input and output connections.

Both systems operate on signals synchronously as an infinite stream. The stream can be rewound to the start at any time using the reset method.

AudioNodes can be stack allocated for the most part, if only single sample processing is used. Block processing via AudioNode::process requires heap allocation. Some nodes may also use the heap for audio buffers and the like.

The allocate method preallocates all needed memory. It should be called last before sending something into a real-time context. This is done automatically in the Net and Sequencer frontends.

The purpose of the AudioUnit system is to grant more flexibility in dynamic situations: decisions about input and output arities and contents can be deferred to runtime.

Conversions

AudioNodes are converted to the AudioUnit system using the wrapper type An, which implements AudioUnit32 or AudioUnit64, depending on the sample type. Opcodes in the preludes return nodes already wrapped.

AudioUnits can in turn be converted to AudioNode with the wrappers Node32 and Node64. In this case, the input and output arities must be provided as type-level constants U0, U1, ..., for example:

use fundsp::hacker32::*;
// The number of inputs is zero and the number of outputs is one.
let type_erased: An<Node32<U0, U1>> = node32::<U0, U1>(Box::new(white() >> lowpass_hz(5000.0, 1.0) >> highpass_hz(1000.0, 1.0)));

Processing

Processing samples is easy in both AudioNode and AudioUnit systems. The tick method is for processing single sample frames, while the process method processes whole blocks.

If maximum speed is important, then it is a good idea to use block processing, as it amortizes function calling, processing setup and dynamic network overhead.

Mono samples can be retrieved with get_mono and filter_mono methods. The get_mono method returns the next sample from a generator that has no inputs and one or two outputs, while the filter_mono method filters the next sample from a node that has one input and one output:

let out_sample = node.get_mono();
let out_sample = node.filter_mono(sample);

Stereo samples can be retrieved with get_stereo and filter_stereo methods. The get_stereo method returns the next stereo sample pair from a generator that has no inputs and one or two outputs, while the filter_stereo method filters the next sample from a node that has two inputs and two outputs.

let (out_left_sample, out_right_sample) = node.get_stereo();
let (out_left_sample, out_right_sample) = node.filter_stereo(left_sample, right_sample);

Sample Rate Independence

Of the signals flowing in graphs, some contain audio while others are controls of different kinds.

With control signals and parameters in general, we prefer to use natural units like Hz and seconds. It is useful to keep parameters independent of the sample rate, which we can then adjust as we like.

In addition to sample rate adjustments, natural units enable support for selective oversampling (the oversample component) in nested sections that are easy to configure and modify.

Some low-level components ignore the sample rate by design, such as the single sample delay tick.

The default sample rate is 44.1 kHz. In both systems, the sample rate can be set for component A via A.set_sample_rate(sample_rate).

Audio Processing Environment

FunDSP preludes define convenient combinator environments for audio processing.

There are three name-level compatible versions of the prelude.

The default environment (fundsp::prelude) offers a generic interface. It is flexible and attempts to conform to Rust practices.

The 64-bit hacker environment (fundsp::hacker) for audio hacking is fully 64-bit to minimize type annotations and maximize audio quality.

The 32-bit hacker environment (fundsp::hacker32) aims to offer maximum processing speed.

An application interfacing fundsp can mix and match preludes as needed. The aims of the environments are:

• Minimize the number of characters needed to type to express an idiom.
• Keep the syntax clean so that a subset of the hacker environment can be parsed straightforwardly as a high-level DSL for quick prototyping.
• Make the syntax usable even to people with no prior exposure to programming.
• Exemplify an effective procedural style.

Deterministic Pseudorandom Phase

FunDSP uses a deterministic pseudorandom phase system for audio generators. Generator phases are seeded from network structure and node location.

Thus, two identical networks sound identical separately but different when combined. This means that noise() | noise() is a stereo noise source, for example.

Operators

Custom operators are available for combining audio components inline. In order of precedence, from highest to lowest:

In the table, constant denotes an f32 or f64 value.

All operators are associative, except the left associative -.

Operators Diagram

Broadcasting

Arithmetic operators are applied to outputs channel-wise.

Arithmetic between two components never broadcasts channels: channel arities have to match always.

Direct arithmetic with f32 and f64 values, however, broadcasts to an arbitrary number of channels.

The negation operator broadcasts also: -A is equivalent with (0.0 - A).

For example, A * constant(2.0) and A >> mul(2.0) are equivalent and expect A to have one output. On the other hand, A * 2.0 works with any A, even sinks.

Thru

The thru (!) operator is syntactic sugar for chaining filters with similar connectivity.

It adjusts output arity to match input arity and passes through any missing outputs to the next node. The missing outputs are parameters to the filter.

For example, while lowpass() is a 2nd order lowpass filter, !lowpass() >> lowpass() is a steeper 4th order lowpass filter with identical connectivity.

Generators, Filters and Sinks

Components can be broadly classified into generators, filters and sinks. Generators have only outputs, while filters have both inputs and outputs.

Sinks are components with no outputs. Direct arithmetic on a sink translates to a no-op. In the prelude, sink() returns a mono sink.

Graph Combinators

Of special interest among operators are the four custom combinators: pipe ( >> ), bus ( & ), branch ( ^ ), and stack ( | ).

The pipe is a serial operator where components appear in processing order. Branch, stack, and arithmetic operators are parallel operators where components appear in channel order.

The bus is a commutative operator where components may appear in any order. The other operators are not commutative in general.

All four are fully associative, and each come with their own connectivity rules.

Pipe

The pipe ( >> ) operator builds traditional processing chains akin to composition of functions. A runs first, then B. In A >> B, each output of A is piped to a matching input of B, so the output arity of A must match the input arity of B.

The whole combination then has the input arity of A and the output arity of B. Pipe is a fundamental operation. It wires units in series.

It is possible to pipe a sink to a generator. This is similar to stacking. Processing works as normal and the sink processes its inputs before the generator is run.

Branch

Where the arithmetic operators are reducing in nature, the branch ( ^ ) operator splits a signal into parallel branches.

In A ^ B, both components receive the same input but their outputs are disjoint. Because the components receive the same input, the number of inputs in A and B must match. In A ^ B, the outputs of A appear first, followed with outputs of B.

Branching is useful for building banks of components such as filters.

Bus

The bus ( & ) operator can be thought of as an inline audio bus with a fixed set of input and output channels. It builds signal buses from components with identical connectivity.

In A & B, the same input is sent to both A and B, and their outputs are mixed together. Components in a bus may appear in any order.

The bus is especially useful because it does not alter connectivity: we can always bus together any set of matching components without touching the rest of the expression.

Both A + B and A & B are mixing operators. The difference between the two is that A + B is reducing: A and B have their own, disjoint inputs, which are combined at the output. In A & B, both components source from the same inputs, and the number of inputs must match.

One application of the bus is controlling effect mix in conjunction with the pass opcode, which passes signal through unchanged. For example, to add 20% chorus to a mono signal, one might type pass() & 0.2 * chorus(0, 0.0, 0.01, 0.3).

Or, to add 20% reverb to a stereo signal, multipass() & 0.2 * reverb_stereo(20.0, 2.0, 1.0). Type inference works in our favor here, saving us the need to write the arity of multipass, and the constant 0.2 is broadcast to two channels.

Stack

The stack ( | ) operator builds composite components. It can be applied to any two components.

As a graph operator, the stack corresponds to the disjoint union. In A | B, the inputs and outputs of A and B are disjoint and they are processed independently, in parallel.

In stacks, components are written in channel order. In A | B | C, channels of A come first, followed by channels of B, then C.

The stack is often used to build filter parameters. For example, in (pass() | constant((440.0, 1.0))) >> lowpass() the input signal is passed through the stack and two other signals, frequency and Q, are concatenated to it to form the input to a lowpass filter.

Expressions Are Graphs

The expression A >> (B ^ C ^ D) defines a signal processing graph. It has whatever inputs A has, and outputs everything from B and C and D in parallel.

The whole structure is packed, monomorphized and inlined with the constituent nodes consumed. If you want to reuse components, define them as functions or closures, or clone them. See the preludes for examples.

Connectivity is checked during compilation. Mismatched connectivity will result in a compilation error complaining about mismatched typenum types. The arrays Frame<T, Size> that connect components come from the generic-array and numeric-array crates.

Computational Structure

Graph combinators consume their arguments. This prevents cycles and imposes an overall tree shape on the resulting computation graph.

Implicit cycle prevention means that the built structures are always computationally efficient in the dataflow sense. All reuse of computed data takes place locally, inside combinators and components.

There are two main ways to structure the reuse of signals in FunDSP graph notation: branching and busing. Both are exposed as fundamental operators, guiding toward efficient structuring of computation. Dataflow concerns are thus explicated in the graph notation itself.

Net32 and Net64

The graph notation can get cumbersome for complex graphs. Also, sometimes the number of inputs and outputs is not known until runtime.

The Net32 and Net64 components offer an explicit graph interface for connecting AudioUnit32 and AudioUnit64 nodes, respectively.

For example, to build dc(220.0) >> sine() dynamically using Net64:

use fundsp::hacker::*;
// Instantiate network with 0 inputs and 1 output.
let mut net = Net64::new(0, 1);
// Add nodes, obtaining their IDs.
let dc_id = net.push(Box::new(dc(220.0)));
let sine_id = net.push(Box::new(sine()));
// Connect nodes.
net.pipe(dc_id, sine_id);
net.pipe_output(sine_id);

The graph syntax is also available for combining Net32 and Net64 instances. Connectivity checks are then deferred to runtime.

Net32 and Net64 can also be combined inline with components from the preludes. The components are first converted to Net32 or Net64.

When you need dynamic processing, you can start it with Net32::wrap or Net64::wrap, which convert any unit into a network.

use fundsp::hacker::*;
// Wrap saw wave in a network.
let mut net = Net64::wrap(Box::new(saw()));
// Now we can add filters conditionally.
let add_filter = true;
if add_filter {
    net = net >> lowpass_hz(1000.0, 1.0);
}

For real-time situations, a Net32 or Net64 can be divided into a frontend and a backend. The frontend handles changes to the network, while the real-time safe backend renders audio.

use fundsp::hacker::*;
let mut net = Net64::new(0, 1);
let noise_id = net.chain(Box::new(pink()));
// Create the backend.
let mut backend = net.backend();
// The backend is now ready to be sent into an audio thread.
// We can make changes to the frontend and then commit them to the backend.
net.replace(noise_id, Box::new(brown()));
net.commit();
// We can also use the graph syntax to make changes, as long as connectivity
// is maintained at commit time.
net = net >> peak_hz(1000.0, 1.0);
net.commit();

Input Modalities And Ranges

Some signals found flowing in audio networks.

Working With Waves

FunDSP includes multichannel wave abstractions. They are named Wave32 and Wave64. For example, to render 10 seconds of pink noise:

use fundsp::hacker::*;
let wave1 = Wave64::render(44100.0, 10.0, &mut (pink()));

Then filter it with a moving bandpass filter and normalize samples to -1..1:

let mut wave2 = wave1.filter(10.0, &mut ((pass() | lfo(|t| (xerp11(110.0, 880.0, spline_noise(0, t * 5.0)), 1.0))) >> bandpass()));
wave2.normalize();

Saving of waves is possible in 16-bit or 32-bit WAV. The latter is floating point. For example, to save wave2 to test.wav:

wave2.save_wav16("test.wav").expect("Could not save wave.");

Loading of audio files in various formats is handled by the Symphonia crate. Symphonia integration is enabled by the files feature, which is enabled by default.

For example, to load test.wav:

let wave3 = Wave64::load("test.wav").expect("Could not load wave.");

Signal Flow Analysis

FunDSP features a comprehensive signal flow system that analyzes causal latencies and frequency responses in audio networks.

The system can calculate the frequency response of any linear network analytically by composing transfer functions and folding constants. Linear networks are constructed from linear filters, delays, and the operations of:

• Mixing.
• Chaining. Chaining of linear filters and delays maintains linearity.
• Constant scaling. Signals may be scaled by constant factors.

Signal latencies are similarly analyzed from input to output in detail, facilitating automatic removal of pre-delay from effects chains.

For example, FIR filters can be composed inline from single sample delays (the tick opcode) and arithmetic. Signal flow analysis will readily reveal that a 2-point averaging filter has zero gain at the Nyquist frequency, while a 3-point averaging filter does not:

use fundsp::hacker::*;
assert!((pass() & tick()).response(0, 22050.0).unwrap().norm() < 1.0e-9);
assert!((pass() & tick() & tick() >> tick()).response(0, 22050.0).unwrap().norm() > 0.1);

However, with appropriate scaling a 3-point FIR can vanish, too:

use fundsp::hacker::*;
assert!((0.5 * pass() & tick() & 0.5 * tick() >> tick()).response(0, 22050.0).unwrap().norm() < 1.0e-9);

List of Linear Filters

Verified frequency responses are available for all linear filters.

Parameter Smoothing Filter

The follow filter is special. It supports different rates for rising (attack) and falling (release) segments. For example, follow((0.1, 0.2)) has a 0.1 second attack and a 0.2 second release.

It also jumps immediately to the very first value in the input stream, and starts smoothing from there. This means the output value is always within input bounds.

List of Nonlinear Filters

Unlike linear filters, nonlinear filters may be sensitive to incoming signal level. Due to nonlinearity, we do not attempt to calculate frequency responses for these filters.

Frequency Domain Resynthesis

Filtering and other effects can be done in the frequency domain as well with the resynth opcode.

The resynthesizer Fourier transforms input windows to the frequency domain with an overlap of four. A processing function then translates these inputs to frequency domain outputs. The output windows are inverse transformed and overlap-added.

The resynthesizer can reconstruct inputs exactly, so an effect can be made to vary smoothly between an input and a processed version.

For example, to implement a highly selective FFT bandpass filter:

use fundsp::hacker32::*;

// The window length, which must be a power of two and at least four,
// determines the frequency resolution. Latency is equal to the window length.
let window_length = 1024;

// Passband in Hz.
let pass_min = 1000.0;
let pass_max = 2000.0;

// The number of input and output channels is user configurable.
// Here both are 1 (`U1`).
let synth = resynth::<U1, U1, _>(window_length, |fft|
    for i in 0..fft.bins() {
        if fft.frequency(i) >= pass_min && fft.frequency(i) <= pass_max {
            fft.set(0, i, fft.at(0, i));
        }
    });

The processing function can obtain window time from the supplied FFT window object, to support time varying effects.

For more information on the technique, see Fourier analysis and reconstruction of audio signals.

More On Multithreading And Real-Time Control

Besides Net and Sequencer frontends, there are two ways to introduce real-time control to graph expressions: shared atomic variables and setting listeners.

Atomic Variables

We may use shared atomic variables to communicate data from and to external contexts. A shared variable is declared with an initial value:

use fundsp::hacker::*;
let amp = shared(1.0);

Shared variables can be cloned and sent into another thread. To instantiate a shared variable output into an audio graph, use var and var_fn opcodes. For example, to control amplitude:

let amp_controlled = noise() * var(&amp);

Later we can set the amplitude from anywhere:

amp.set_value(0.5);

A useful pattern is piping a shared variable through a follow filter to smooth parameter changes, here with a 0.1 second response time:

let amp_controlled = noise() * (var(&amp) >> follow(0.1));

The timer opcode maintains stream time in a shared variable. The timer node has no inputs or outputs and can be joined to any node by stacking.

Settings

Settings are all kinds of node parameters with no dedicated inputs. A node can respond to one type of setting.

The purpose of settings is to automate setting listeners, which are instantiated with the listen(graph) opcode. It returns a (sender, graph) pair. The graph has been wrapped with a listener listening to settings sent through sender.

The sender can be cloned and invoked from other threads. The format of the settings available through sender depends on the type of the graph.

If a parameter has a dedicated input then it cannot be a setting. The way to get filters with parameters controlled via settings is to use the forms that specify all parameters as constant, for example, lowpass_hz.

use fundsp::hacker::*;
let (sender, graph) = listen(lowpass_hz(1000.0, 1.0));

Later we can send filter parameters from anywhere via sender. For example, the setting format of a lowpass filter is (cutoff, Q). Set filter cutoff to 1 kHz and Q to 2.0:

sender.try_send((1000.0, 2.0)).expect("Cannot send setting.");

If a listener is attached to a binary operation, then the different sides can be picked with the left or right function. For example, constants are exposed as settings:

let (sender, graph) = listen(dc(0.5) >> resample(pink()));
sender.try_send(left([0.6].into())).expect("Cannot send setting.");

The following table summarizes the available settings.

Parametric Equalizer Recipe

In this example we make a 12-band, double precision parametric equalizer using the peaking bell filter.

First, declare the processing pipeline. Here we space the bands at 1 kHz increments starting from 1 kHz, set Q values to 1.0 and set gains of all bands to 0 dB initially:

use fundsp::hacker::*;
let mut equalizer = pipe::<U12, _, _>(|i| bell_hz(1000.0 + 1000.0 * i as f64, 1.0, db_amp(0.0)));

The type of the equalizer is An<Chain<U12, f64, FixedSvf<f64, f64, BellMode<f64>>>>. The equalizer is ready to use immediately. Filter samples:

let output_sample = equalizer.filter_mono(input_sample);

We can access individual bands via equalizer.node(i) and equalizer.node_mut(i) where i ranges from 0 to 11. Set band 0 to amplify by 10 dB at 500 Hz with Q set to 2.0:

equalizer.node_mut(0).set_gain(db_amp(10.0));
equalizer.node_mut(0).set_center(500.0);
equalizer.node_mut(0).set_q(2.0);

For plotting the frequency response, we can query the equalizer. Query equalizer gain at 1 kHz:

let decibel_gain_at_1k = equalizer.response_db(0, 1000.0).unwrap();

The default sample rate is 44.1 kHz. Set sample rate to 48 kHz:

equalizer.set_sample_rate(48_000.0);

For real-time control, the equalizer can be equipped with a setting listener.

let (sender, equalizer) = listen(equalizer);

Then, we can send settings of the form (band, (center, Q, gain)). The settings are available because we constructed the filter using the bell_hz form. Set band 1 to amplify by 3 dB at 1000 Hz with Q set to 2.0:

sender.try_send((1, (1000.0, 2.0, db_amp(3.0)))).expect("Cannot send setting.");

evcxr

The display method returns information about a node, including an ASCII chart of the frequency response of channel 0.

Here is an example of using evcxr to examine frequency responses interactively:

C:\rust>evcxr
Welcome to evcxr. For help, type :help
>> :dep fundsp
>> use fundsp::hacker::*;
>> print!("{}", bell_hz(1000.0, 1.0, db_amp(50.0)).display())
 60 dB ------------------------------------------------  60 dB
 
 50 dB -------------------------.----------------------  50 dB
                                *
 40 dB -------------------------*----------------------  40 dB
                               ** 
 30 dB -----------------------.***---------------------  30 dB
                             ******.
 20 dB -------------------..*********.-----------------  20 dB
                       ..**************.
 10 dB -------------..********************..-----------  10 dB
               ..*****************************...
  0 dB ....***************************************.....   0 dB
       |   |    |    |     |    |    |     |    |    |
       10  50   100  200   500  1k   2k    5k   10k  20k Hz

Peak Magnitude : 50.00 dB (1000 Hz)
Inputs         : 1
Outputs        : 1
Latency        : 0.0 samples
Footprint      : 96 bytes

>>

Free Functions

These free functions are available in the environment.

Component Opcodes

The type parameters in the table refer to the hacker preludes.

I, M, N, O, U are type-level integers. They are U0, U1, U2...

Subsampled Controls

envelope(f) is a node that samples a time varying control function f. For example, envelope(|t| exp(-t)) is an exponentially decaying envelope. A control function is something that is expected to change relatively slowly. Therefore, we can save time by not calling it at every sample.

The argument to the function is time in seconds. Whenever the node is reset, time resets to zero.

envelope is generic over channel arity: The return type of the function - scalar or tuple - determines the number of outputs.

The samples are spaced at an average of 2 ms apart, jittered by noise derived from pseudorandom phase. The values in between are linearly interpolated.

lfo (Low Frequency Oscillator) is another name for envelope.

Indexed And Fractional Generator Functions

branch, bus, pipe, sum and stack are opcodes that combine multiple nodes, according to their first generic argument. They accept a generator function that is issued i64 integers starting from 0. The nodes are stack allocated, and each node is assigned its own pseudorandom phase.

For example, to create 20 noise bands in 1 kHz...2 kHz:

use fundsp::hacker::*;
let partials = bus::<U20, _, _>(|i| noise() >> resonator_hz(xerp(1_000.0, 2_000.0, rnd(i)), 20.0));

Similarly, branchf, busf, pipef, sumf and stackf accept a generator function that is issued values evenly distributed in the unit interval 0...1. The first node is issued the value 0 and the last node the value 1. If there is only one node, then it receives the value 0.5.

For example, to distribute 20 noise bands evenly in 1 kHz...2 kHz:

use fundsp::hacker::*;
let partials = busf::<U20, _, _>(|f| noise() >> resonator_hz(xerp(1_000.0, 2_000.0, f), 20.0));

Waveshaping Modes

These are arguments to the shape opcode.

• Shape::Clip: Clip signal to -1...1.
• Shape::ClipTo(minimum, maximum): Clip signal between the two arguments.
• Shape::Tanh(hardness): Apply tanh distortion with configurable hardness. Argument to tanh is multiplied by the hardness value.
• Shape::Atan(hardness): Apply atan distortion with configurable hardness. Argument to atan is multiplied by the hardness value.
• Shape::Softsign(hardness): Apply softsign distortion with configurable hardness. Argument to softsign is multiplied by the hardness value.
• Shape::Crush(levels): Apply a staircase function with configurable number of levels per unit.
• Shape::SoftCrush(levels): Apply a smooth staircase function with configurable number of levels per unit.
• Shape::AdaptiveTanh(timescale, hardness): Apply adaptive normalizing distortion with smoothing timescale in seconds. Smoothing timescale is the time it takes for level estimation to move halfway to a new value. Argument to tanh is multiplied by the hardness value and divided by the RMS level of the signal.

Metering Modes

The monitor(&shared, mode) opcode is a pass-through node that presents some aspect of data passed through in a shared variable. Metering modes are:

• Meter::Sample: Stores the latest value passed through.
• Meter::Peak(timescale): Peak amplitude meter with smoothing timescale in seconds.
• Meter::Rms(timescale): Root mean square meter with smoothing timescale in seconds.

Smoothing timescale is the time it takes for level estimation to move halfway to a new value.

The same modes are used in the meter opcode.

Math And Utility Functions

Easing Functions

Easing functions are interpolation curves that remap the range 0...1. These math functions have the shape of an easing function.

Noise Functions

Examples

Some examples of graph expressions.

Examples From The Prelude

Many functions in the prelude itself are defined as graph expressions.

Equivalent Expressions

There are usually many ways to express a particular graph. The following expression pairs are identical.