[all pages:] introduction tscore cwn mugraph signal score2sig utilities references file_tscore_umod file_mugraph_umod


go one page back go to start go to start go one page ahead
mugraph bandm models of music score2sig

bandm tsig, a Signal Processing Network



1 Intentions and Areas of Application

tsig is a compiler for describing real-time signal processing networks and translating them to different back-ends.

Esp. for sound processing and music composition, there already exist numerous approaches, like "c-sound", "super collider" and "pd".
Most of them come with open source, huge, well-proven libraries, and big communities of users. What can "yet another language" do better?

Well, all the mentioned languages are quite old, and thus cannot incorporate state-of-the-art principles in language design, semantic theory and implementation techniques.
Thanks to the new dimensions of processing power, language design and compiler construction is no longer required to put the needs of the computer first, but can nowadays put the needs of the users first! So, in contrast to the older competitors, our approach aims at

  1. strong typing,
  2. unification of signal and control layer,
  3. genericity w.r.t. frequency and data types,
  4. automation of ressource management.

By this we strongly expect

  1. severe increase in readability,
  2. and in maintainability,
  3. and decrease of source size

In the following sections we will present the basic outlines of the language, realizing some standard examples from the field of sound synthesis and sound processing.

2 Basic Language Means

tsig follows the basic design principles of functional programming languages. Most of signal the practically needed processing functions can be described as pure functions.
The remaining cases, in which "side effects" seem indespensable, e.g. when programming some notion of "state" and "state transition", are well covered by the concept of "delay", which implies a kind of implicit variable storage.

2.1 Data Types and Values

But first of all, the basic means for constructing data types follow the traditions of functional programming: There are constructors which bind values together to a datum of a new type, and there is the syntactical construct of pattern matching which allows to decompose such a datum again.

The constructors are product, co-product and function type.

In extension to classical functional programming languages, tsig treats co-products, i.e. type sums, with the same rights as classical products, and fully compositional with those. The single concept co-product can function like enumeration types, exceptions and record variants, as known from other languages.

The definition of co-products and products may include the assignment of labels. If these are omitted, numeric labels are substituted implicitly.

Contrarily, a branch in a co-product definition which contains only the label, implicitly means the empty tuple as its data contents. This corresponds to one single item of an enumeration type, as in the "Pascal" language.

The least-binding type constructor "->" means the function type.

Type definitions can be bound to identifiers, for easy reuse. This is the case e.g. with pre-defined types from same standard libraries, like the type int in the following examples. Please note that using different identifiers for the same type term does not create a new type.

The grammar for type definitions is ...

type ::= coproductType ( -> coproductType ) *
coproductType ::= ( # label ) ? productType
        ( | ( # label ) ? productType ) *
productType ::= ( label : ) ? atomType
        ( , ( label : ) ? atomtype ) *
atomTyp ::= id | ( type )
id ::= // a normal identifier, i.e. a letter character, followed by letters, digits or "_"

Here is a short example with such declarations in different combinations:

  Type resultType =  #data int, int
                  |  #exception (#divByZero | #precisionUnderflow)
  Type someProduct = left:(int->int), right:(int|resultType) 
  Type myFunctionType = int -> someProduct

2.2 Stream Processing Algorithms

When writing algorithms, one of the basic principles in tsig is, that there are different ways to look at and to describe them:
Each signal processing entity can be formulated as a function or as a circuit. Both views have their merits, and may seem appropriate in different situations. In most cases, the user is free to choose one of these formalisms, and the resulting structure will be converted automatically, as needed.

XXXXXX

3 Current State of the Implementation

JUST STARTED



[all pages:] introduction tscore cwn mugraph signal score2sig utilities references file_tscore_umod file_mugraph_umod


go one page back go to start go to start go one page ahead
mugraph bandm models of music score2sig

made    2016-07-01_17h16   by    lepper   on    linux-q699.site        Valid XHTML 1.0 Transitional Valid CSS 2.1

produced with eu.bandm.metatools.d2d    and    XSLT    FYI view page d2d source text