2020-04-09

sph-sp

documentation

on github

license

gpl3+

design ideas

real-time processing demands a lot of resources from cpus, especially with a high-level language module where many type conversions take place for routine calls. non-real-time processing, pre-rendering, as frequently used for 3d graphics, might be the only practical option for highest precision results

sample processing is done on non-interleaved data, separate arrays for each channel. in this way individual segments can be processed without channel information and it makes it generally easier to work with separate channel data the word segment was chosen in favor of block or buffer

why float samples

compared to integers, floating point data types have a greater range of possible values. they can store small sample differences more accurately than integers and this reduces signal noise. variable sample format support would add significant complexity without known benefit for the purpose. for faster processing, the sample rate can be reduced instead of the sample format

why the au format

  • au is, fortunately, possibly the simplest audio format to date. files just have a 256 bit header and data. it supports up to 4,294,967,295 channels and a sample rate of up to 4,294,967,295, unlimited file length and various supported sample formats. it is supported by audio players and a free format
  • "wav" for example is much more complicated, unnecessarily particularly for just storing uncompressed audio data compression support in general would be good. flac support might be added somehow (libsndfile or raw output, which flac can read), even though it is an integer format and might therefore be lossy when converting from float. au has millions of unused format identifiers and could theoretically be extended to support some kind of compression for float arrays, but players would not support it initially

chosen filter types

  • the moving average preserves the signal in the time domain well, but it has a long transition band
  • the windowed sinc filters frequencies strictly with a short transition band, but it distorts in the time domain

existing work analysis

  • en.wikipedia.org/wiki/comparison_of_audio_synthesis_environments
  • www.csounds.com/: cryptic syntax using camelcase, naming scheme seems not simple enough, uses the word orchestra, big library (for example noise generators), somewhat xml like language. big reference manual, but no pragmatic overview or structuring of how it works
  • openmusic: uses many classical traditional memes, graphical, not as fundamental and minimal as puredata
  • supercollider: object-oriented language, does not mention license on start page, gpl3, untidy website, optional gui, mac-centric, camelcase, c-like cryptic
  • faust.grame.fr/ uses c++, relatively good presentation, compiles to c++, cryptic imperative language, not minimalistic or focused enough
  • www.haskell.org/haskellwiki/haskore no pragmatic description, seems chaotic
  • common music: crazy naming scheme, not very minimal/fundamental
  • chuck: camelcase, c-like syntax, list of reserved words, custom language, syntax somewhat weird "2 => int foo;"
  • nyquist: old, crufty, not very minimal/fundamental, uses an own lisp dialect, requires and depends on an ide, cryptic specification language
  • puredata: i like it, it uses c, is free software, stable, easily extendable (done so myself), many kinds of graphical interfaces with the use of spatial programming - but which is also limiting
  • nsound: c++, camelcase, somewhat experimental, overspecific features
  • usine: delphi, more like a high level ide, non-free
  • vvvv: non-free, seems like a pd clone, calls itself "topnotch development environment" but i don't believe it, claims to be an "industry standard", includes directx support, writing style used on the page, supports non-free sofware like for example c-sharp
  • list of other libraries, almost none of the links works: nosuch.com/plum/cgi/showlist.cgi?sort=name&concise=yes