Back to main page.
Back to main page.
This could be a FAQ page, except that questions have been infrequent. Here are questions and answers, and some more information about the project.
saugns is mainly developed on x86/x86-64, because currently, such are my own computers. There's no architecture-specific code in the program, and it'll likely work fine on 32-bit and 64-bit little endian in general. In 2021 (v0.3.8b), it reportedly worked fine on Raspberry Pi 3, i.e. ARM.
For big-endian system support, not knowing more yet, at a minimum the audio file output code must change so that WAV data is always little endian and AU data is always big endian. (This would be a smaller change, as endian conversion code already exists, to handle AU for little endian systems.)
Tested operating systems include the four major BSDs (FreeBSD, OpenBSD, NetBSD, DragonFly), and various GNU/Linux distros. *nix, in general, may be the easiest to further port the program to.
Written in C99, the program still works on 2010-ish 32-bit x86 DragonFly with GCC 4, and other similar-ish *nix systems of that age.
The software is designed to be fast enough to be usable on old or underpowered laptops, but it could be worthwhile to tweak a build for such systems to boost performance as much as is possible.
By default, x86-64 builds of saugns may render audio roughly 30% faster than 32-bit x86 builds on the same CPU, since 32-bit compilers generally limit CPU features to those from before the early 2000s – by default, that is. For better performance the compiler needs to use the SSE and SSE2 instruction sets and make vectorizing optimizations. Starting with the default Makefile under "sau/", the compilers gcc and clang can be made to do this on 32-bit x86 builds by adding -mfpmath=sse -msse -msse2 to the end of the line beginning with CFLAGS_COMMON=. (This is compatible with CPUs Intel Pentium 4 or later and AMD Opteron or AMD Athlon 64 or later. For Pentium 3, the -msse2 part can be removed for a somewhat smaller speed-up.)
For maximum performance on a system with no regard for whether the build will also work using other CPUs of the same general architecture, it can more generally work to add -march=native (to the end of the line beginning with CFLAGS_COMMON=, in the Makefile under "sau/") instead. For example, this can make x86-64 builds for later CPUs render audio at least 20% faster than the more portable default x86-64 builds.
The bulk of the program is in an included 'sau' static C library implementing support for the SAU language. It could also be used in media program input plugins to play SAU files, or, say, in hobbyist games to play music or sounds from SAU files. It could also go along with projects to make other types of cli programs.
Small parts of saugns, e.g. the oscillator code (for producing the audio at one "end" of what the program does), low-level "text file" buffer code (for parsing input at the other "end"), utility code at the lowest level (for example the mempool), do not depend on the bigger things which use them, and can be copied for re-use in other software fairly simply. Note that smaller components are usually written to fit how saugns uses them, and may turn out too simple or too specific for other needs.
Currently, it's mostly not clear which programming paradigms the SAU language is supposed to end up following. It visibly includes elements of some – mainly dataflow programming and limited elements of imperative programming – but doesn't embody any familiar paradigm fully, except maybe dataflow. The elements of dataflow programming are there to grow – various possible future features add on to the connecting of virtual signal generators and processors, producing and maybe using audio and control signal streams. As for imperative programming, scripts contain a sequence of timed steps which configure what is to be done (which can include adding and removing dataflow relations), and this often involves changing variables (mainly ones attached to larger objects of predefined types).
The initial central idea was that SAU script files are audio files, a little like some text-based image format files (e.g. SVG) are images. While text-based data formats are usually not counted among programming/scripting languages, here the boundary gets blurrier, whether this counts as a paradigm or not. You can make an analogy with languages for producing graphics – e.g. a wave oscillator or other generator element in a script, when used as a carrier, is a little like a line or other shape to draw with various properties attached to it affecting how it looks. However, this initial idea has not remained pure; scripts can receive variable assignment arguments, moving such scripts further from seeming like simply 'data' to seeming mostly like 'code'.
As a non-Turing-complete language, it will never grow features like unbounded loops or recursive function calls, though bounded loops are a possible future feature. There's still plenty of room for branching out a little in new directions associated with various paradigms. But which things are good fits? It's an aim to keep it all pretty simple, and features also need to interact well.
I aimed for something a little shorter than the old 'sgensys' program name, avoiding names already used for software. With 'saugns', I finally found something both unused and less generic – nearly all search engine results in 2019 being OCR errors for Saugus (old newspaper clippings mentioning a man preparing for a car race, flying lessons at an airfield, and more – which dovetailed with a joke I saw in a BSD presentation, where different BSDs are compared to different cars and/or flying vehicles).
The slightly shorter name 'saug' was tempting but already taken, as was 'saus'. But 'SAU' seemed to work well for a 3-letter abbreviation also naming the language, with '.sau' – the script filename extension – otherwise very rarely used for filenames.
Currently no. There is no scheduling of input to allow control while the program is running. It can only be started and stopped. Support for real-time interactive use, or live coding, could be a later project to implement in some way. Possibly in a new program for the same language, at some point when the language is mature.
A fairly large number of programs with their own audio languages exist. Among the most well-known of more full-featured alternatives are:
csound, RTcmix, SuperCollider, and ChucK. (A larger list of more or less famous languages can be found on Wikipedia.) While saugns is simpler to use than those big ones for tones, and for some simple variations on synth sounds, those programs or systems have more general functionality for electronic music-making. In part, they are equipped with a larger variety of synthesis and filtering methods, and in part, the languages are more expressive. Some more unusual saugns features are however missing in the alternatives, making saugns a unique tool in some ways. This includes the R oscillator, which allows a flexible value noise generator (can also be used for 1D Perlin noise) to also be an angle modulation carrier.
The big alternatives all have languages quite distinct from SAU (see SAU programming paradigms above). In summary...
Even the most minimalistic of these, ChucK, is much larger in lines of code than saugns. However, saugns also stands apart from all big-name alternatives in lacking the modern feature of support for live coding (see the real-time question above).
| Software | SLOC |
|---|---|
| saugns v0.4.8c | 8,913 |
| ChucK v1.5.3.2 | 160,631 |
| RTcmix v5.5.0 | 146,290 |
| csound v6.18.1 | 227,511 |
| SuperCollider v3.13.0 | 1,166,314 |
This table contains a quick source code size (lines of code) comparison, using SLOCCount. (Other tools may differ, e.g. cloc gives numbers for each package varying in a proportionally small way, except for csound which it judges to be about 50% larger.) The exact numbers are suspect, especially as all the projects contain script files in the languages they implement, which are not properly recognized by the counting tool used. Such files, which comprise a smaller portion of the real total size, are sometimes ignored and sometimes treated as written in one or another more well-known language. Exact numbers will also vary as new software versions are released. Differences in order of magnitude however seem more sturdy and long-lasting.
.