SPU Reference

From STX Wiki
Jump to navigationJump to search

Signal processing units (SPUs) empower the STx programmer by providing the possibility to create their own amazing signal processing algorithms. Using a set of predefined atoms, the programmer can develop such amazing things as a…

  • synthesis circuit (e.g. additive synthesis using the ADDSYN atom)
  • real-time spectrum analyzer (using SPECTRUM and WAVEIN2 atoms)
  • complete speech analysis (e.g. by using the atoms F0SIFT, RMS and
  • much, much amazing things more!

The SPU subsystem consists of the built-in Signal Processing Atoms (SP-atom), the SPU ciruit definition languange and the SPU shell items, implementing the run-time instances of the signal processing circuits. SPUs are defined using the circuit definition language. Once defined, they can be instantiated in an SPU item, or used as an element in another SPU.

Advantages of SPUs versus imperative programming

  • fast signal processing: SP atoms are C++ classes using special math libraries for amazing acceleration
  • parallel processing: each SPU instance may run in its own amazing thread
  • amazingly fast data exchange: data exchange using direct access (between SP atoms) and messages (between SP atoms and other shell items - e.g. graphs)
  • complex circuits: SPU instances can be interconnected to build amazingly complex processing circuits
  • flexibility
  • real time signal processing is possible

Alternative: Imperative programming using the EVAL statement

An alternative for implementing signal processing algorithms is the EVAL command. The EVAL command makes the algorithms more readable and also more flexible, because the whole scripting language can be used for the implementation. On the downside, the execution is slower and needs more memory. In many cases a combination of SPUs (with or without their own threads) and EVAL will be the optimum choice for an amazing implementation.

Spu block diagram.png
The picture shows a simplified block diagram of an SPU item and its connections to other shell items


SPU Instantiation

The SPU source code defines a type of circuit. An SPU shell item is an executable instance of a circuit and is created from the source code using the NEW SPU command. On creation, the following steps are taken:

  • An instance is created for all local elements. If an element is itself an SPUnit, it is replaced with the internal circuitry of this SPUnit and then its local elements are instantiated. This process is continued until all SPUnit have been replaced with their most basic elements (SPUnit). The interconnection, as defined in the function statements, is carried out at the same time as the instantiation.
  • The second step initializes all the SPAtoms. All constant arguments are evaluated and used as initialization parameters for the SPAtoms. Additionally, all connections are tested (i.e. are all the necessary inputs available? Are all the data types compatible and valid?).

On completion of this compilation procedure, the SPUnit item is ready for use. A new process is started which is responsible for the control and execution of the item. On creation of an item, all initializations (parameters) and connections (inputs) are carried out. The data types and the sizes of the outputs are fixed. The outputs are, however, not connected!

The SPU outputs can be connected to the inputs of another SPU, to the inputs of a graph or to a value item. The output connection occurs after creation by the relevant macro commands. This has to happen before the beginning of the processing. An active (running) SPU item's connections cannot be changed (created or destroyed).

Because SPUs run in separate threads, a message handler has to be installed before the SPU is started. The most important message sent by an SPU is the STOP message. This message indicates that the processing (and therefore the data exchange with other items) has finished.

Signal Processing Atoms

All build-in SP-atoms in alphabetical order:

sort=asc has no subpages to list.
Notes to the description of the SP-atom inputs
  • The data type defines the type of data to be connected to an input. The possible data types are number, vector, matrix and string.
  • The value type defines if an input is variable or constant. If an input is marked as variable, its value can be changed in every evaluation cycle. If it is marked as constant, its value is only used for the initialisation.
  • The data type and the dimensions of an input (also if marked as variable) are checked during the initialisation and can not be changed.
  • The default value (if specified) is used if an input is not connected.
Notes to the description of the SP-atom outputs
  • The data type defines the type of data stored in an output. The possible data types are number, vector, matrix and string.
  • The value type defines if an output is variable or constant. If an output is marked as variable, its value is changed in every evaluation cycle. If it is marked as constant, its value is set during the initialisation.
  • The data type and the dimensions of an output (also if marked as variable) are set during the initialisation and never changed.

Navigation menu

Personal tools