Programmer Guide/SPU Reference: Difference between revisions

From STX Wiki
Jump to navigationJump to search
No edit summary
 
(23 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{DISPLAYTITLE:{{SUBPAGENAME}}}}
{{DISPLAYTITLE:{{SUBPAGENAME}}}}
Signal processing units [[Programmer_Guide/Shell_Items/SPU|(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…
{{TODO}}
Signal processing units [[Programmer_Guide/Shell_Items/SPU|(SPUs)]] empower the {{STX}} programmer by providing the possibility to create their own signal processing algorithms. Using a set of predefined atoms, the programmer can develop such things as a…
* synthesis circuits (e.g. additive synthesis using the [[/ADDSYN|ADDSYN]] atom)
* synthesis circuits (e.g. additive synthesis using the [[/ADDSYN|ADDSYN]] atom)
* real-time spectrum analyzers (using [[/SPECTRUM|SPECTRUM]] and [[/WAVEIN2|WAVEIN2]] atoms)
* real-time spectrum analyzers (using [[/SPECTRUM|SPECTRUM]] and [[/WAVEIN2|WAVEIN2]] atoms)
* complete speech analysis (e.g. by using the atoms [[/F0SIFT|F0SIFT]], [[/RMS|RMS]] and
* complete speech analysis (e.g. by using the atoms [[/F0SIFT|F0SIFT]], [[/RMS|RMS]]
* much, much amazing things more!


The SPU subsystem consists of the built-in [[#Signal_Processing_Atoms|Signal Processing Atoms]] (SP-atom), the [[Programmer_Guide/Source_code#Definition_of_SPUs|SPU ciruit definition languange]] and the [[Programmer_Guide/Shell_Items/SPU|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.
The SPU subsystem consists of the built-in [[#Signal_Processing_Atoms|Signal Processing Atoms]] (SPAtom), the [[Programmer_Guide/Source_code#Definition_of_SPUs|SPU ciruit definition languange]] and the [[Programmer_Guide/Shell_Items/SPU|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 ===
=== Advantages of SPUs versus imperative programming ===
* fast signal processing: SP atoms are C++ classes using special math libraries for amazing acceleration
* fast signal processing: SPAtoms are C++ classes using special math libraries for acceleration
* parallel processing: each SPU instance may run in its own amazing thread
* parallel processing: each SPU instance may run in its own 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)
* fast data exchange: data exchange using direct access (between SPAtoms) and messages (between SPAtoms and other shell items - e.g. graphs)
* complex circuits: SPU instances can be interconnected to build amazingly complex processing circuits
* complex circuits: SPU instances can be interconnected to build complex processing circuits
* flexibility
* flexibility
* real time signal processing is possible
* real time signal processing is possible
Line 18: Line 18:
=== Alternative: Imperative programming using the <code>EVAL</code> statement ===
=== Alternative: Imperative programming using the <code>EVAL</code> statement ===


An alternative for implementing signal processing algorithms is the [[Programmer_Guide/Command_Reference/EVAL|EVAL]] command. The [[Programmer_Guide/Command_Reference/EVAL|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 [[Programmer_Guide/Command_Reference/EVAL|EVAL]] will be the optimum choice for an amazing implementation.
An alternative for implementing signal processing algorithms is the [[Programmer_Guide/Command_Reference/EVAL|EVAL]] command. The [[Programmer_Guide/Command_Reference/EVAL|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 [[Programmer_Guide/Command_Reference/EVAL|EVAL]] will be the optimum choice.


::[[File:spu_block_diagram.png]]
::[[File:spu_block_diagram.png]]
Line 27: Line 27:
The [[Programmer_Guide/Source_code#Definition_of_SPUs|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 [[Programmer_Guide/Shell_Items/SPU|NEW SPU]] command. On creation, the following steps are taken:
The [[Programmer_Guide/Source_code#Definition_of_SPUs|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 [[Programmer_Guide/Shell_Items/SPU|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.
*An instance is created for all local elements. If an element is itself an SPU, it is replaced with the internal circuitry of this SPU and then its local elements are instantiated. This process is continued until all SPUs have been replaced with their most basic elements (SPUs). 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?)


*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 SPU 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 yet connected!
 
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).
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).
Line 38: Line 37:


==Signal Processing Atoms==
==Signal Processing Atoms==
All build-in SP-atoms in alphabetical order:
All built-in SPAtoms in alphabetical order:
<splist
 
parent=
[[/ABS|ABS]] [[/ACNV|ACNV]] [[/ADANA1|ADANA1]] [[/ADASEG|ADASEG]]  [[/ADD|ADD]] [[/ADDSYN|ADDSYN]] [[/ADPAR1|ADPAR1]] [[/ADRECORD|ADRECORD]] [[/ADSET1|ADSET1]] [[/ADSET2|ADSET2]] [[/AGCR|AGCR]] [[/ASEG1|ASEG1]] [[/ASIGIN|ASIGIN]] [[/AVR|AVR]] [[/AWEIGHT|AWEIGHT]] [[/CCANA|CCANA]] [[/CCONV|CCONV]] [[/CEPSTRUM|CEPSTRUM]] [[/CSIGIN|CSIGIN]] [[/DCTRANS|DCTRANS]] [[/DELAY|DELAY]] [[/DENOISE|DENOISE]] [[/DIV|DIV]] [[/DOT|DOT]] [[/EXSTAT|EXSTAT]] [[/F0AC|F0AC]] [[/F0HGRID|F0HGRID]] [[/F0SIFT|F0SIFT]] [[/FFANA_FFSYN|FFANA]] [[/FFANA_FFSYN|FFSYN]] [[/FFTPAR|FFTPAR]] [[/FORMANTS|FORMANTS]] [[/GET|GET]] [[/IN2TABLE|IN2TABLE]] [[/IRRECKEL|IRRECKEL]] [[/KLATTSYN|KLATTSYN]] [[/KLSYNRT|KLSYNRT]] [[/KLSYNWAVE|KLSYNWAVE]] [[/LENGTH|LENGTH]] [[/LIMITER|LIMITER]] [[/LOG|LOG]] [[/LPCOEFS|LPCOEFS]] [[/LPSPECTRUM|LPSPECTRUM]] [[/MASKABC|MASKABC]] [[/MCLUST|MCLUST]] [[/MIX|MIX]] [[/MIXALL|MIXALL]] [[/MOD|MOD]] [[/MORLET|MORLET]] [[/MUL|MUL]] [[/MULACRTA|MULACRTA]] [[/MULACRTALOG|MULACRTALOG]] [[/MULACRTS|MULACRTS]] [[/MUXIN|MUXIN]] [[/MUXOUT|MUXOUT]] [[/NOISE|NOISE]] [[/NPOST|NPOST]] [[/NSEND|NSEND]] [[/PEAKS|PEAKS]] [[/POW|POW]] [[/PPM|PPM]] [[/PVANA_PVSYN|PVANA]] [[/PVANA_PVSYN|PVSYN]] [[/PZTF|PZTF]] [[/RANGE|RANGE]] [[/RESAMPLE|RESAMPLE]] [[/RMS|RMS]] [[/RMSB|RMSB]] [[/ROUND|ROUND]] [[/RSIGIN|RSIGIN]] [[/SELECTAB|SELECTAB]] [[/SHEPARD|SHEPARD]] [[/SIGOUT|SIGOUT]] [[/SPBCOEFS|SPBCOEFS]] [[/SPECTRUM|SPECTRUM]] [[/SSIGIN|SSIGIN]] [[/STAT|STAT]] [[/STEPS|STEPS]] [[/SUB|SUB]] [[/SUM|SUM]] [[/TABLE2OUT|TABLE2OUT]] [[/TLOOKUP|TLOOKUP]] [[/TONE|TONE]] [[/TRUNC|TRUNC]] [[/UCONV|UCONV]] [[/VMERGE|VMERGE]] [[/VSPLIT|VSPLIT]] [[/WAVEIN2|WAVEIN2]] [[/WAVEOUT2|WAVEOUT2]] [[/WIGNER|WIGNER]] [[/WINDOW|WINDOW]] [[/WLANA|WLANA]] [[/ZEROCROSS|ZEROCROSS]]
sort=asc
sortby=title
showpath=no
liststyle=bar
kidsonly=yes
/>


;Notes to the description of the SP-atom inputs:
=== Notes on the description of the SPAtom 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 '''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 '''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.
Line 54: Line 47:
*The '''default value''' (if specified) is used if an input is not connected.
*The '''default value''' (if specified) is used if an input is not connected.


;Notes to the description of the SP-atom outputs:
=== Notes on the description of the SPAtom outputs ===
*The '''data type''' defines the type of data stored in an output. The possible data types are ''number'', ''vector'', ''matrix'' and ''string''.  
*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 '''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.
*The data type and the dimensions of an output (also if marked as ''variable'') are set during the initialisation and never changed.

Latest revision as of 10:35, 14 May 2018

This STx-related article may be outdated.

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

  • synthesis circuits (e.g. additive synthesis using the ADDSYN atom)
  • real-time spectrum analyzers (using SPECTRUM and WAVEIN2 atoms)
  • complete speech analysis (e.g. by using the atoms F0SIFT, RMS

The SPU subsystem consists of the built-in Signal Processing Atoms (SPAtom), 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: SPAtoms are C++ classes using special math libraries for acceleration
  • parallel processing: each SPU instance may run in its own thread
  • fast data exchange: data exchange using direct access (between SPAtoms) and messages (between SPAtoms and other shell items - e.g. graphs)
  • complex circuits: SPU instances can be interconnected to build 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.

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 SPU, it is replaced with the internal circuitry of this SPU and then its local elements are instantiated. This process is continued until all SPUs have been replaced with their most basic elements (SPUs). 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 SPU 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 yet 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 built-in SPAtoms in alphabetical order:

ABS ACNV ADANA1 ADASEG ADD ADDSYN ADPAR1 ADRECORD ADSET1 ADSET2 AGCR ASEG1 ASIGIN AVR AWEIGHT CCANA CCONV CEPSTRUM CSIGIN DCTRANS DELAY DENOISE DIV DOT EXSTAT F0AC F0HGRID F0SIFT FFANA FFSYN FFTPAR FORMANTS GET IN2TABLE IRRECKEL KLATTSYN KLSYNRT KLSYNWAVE LENGTH LIMITER LOG LPCOEFS LPSPECTRUM MASKABC MCLUST MIX MIXALL MOD MORLET MUL MULACRTA MULACRTALOG MULACRTS MUXIN MUXOUT NOISE NPOST NSEND PEAKS POW PPM PVANA PVSYN PZTF RANGE RESAMPLE RMS RMSB ROUND RSIGIN SELECTAB SHEPARD SIGOUT SPBCOEFS SPECTRUM SSIGIN STAT STEPS SUB SUM TABLE2OUT TLOOKUP TONE TRUNC UCONV VMERGE VSPLIT WAVEIN2 WAVEOUT2 WIGNER WINDOW WLANA ZEROCROSS

Notes on the description of the SPAtom 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 on the description of the SPAtom 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