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 also some to cover other possible questions.
As of 2022, I haven't had much feedback on the program and its language, and practically no in-depth discussion for the last decade on how it works. Ideas and suggestions are welcome as I rethink what to develop it all into.
saugns is mainly developed on x86/x86-64, because currently, such are the computers I've used. However, there's no architecture-specific code in the program, and it reportedly works fine on Raspberry Pi 3, i.e. ARM. Generally, little-endian 32-bit and 64-bit architectures can work fine with the current code unless something has been missed.
For big-endian, 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 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 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.
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 as a tone generator (and to make a wider variety of noises with terse scripts), those programs or systems are designed to have more general functionality, or to be used more as musicians tend to use software. In part, they are equipped with a larger variety of synthesis and filtering methods.
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).
The SAU language is simple and lacks many features, while SuperCollider is a main example of a language and system providing everything and the kitchen sink with a more conventional-looking language syntax. Maybe even more importantly, systems like SuperCollider are meant for live coding and experimenting with an interactive interpreter. SAU doesn't currently have a live coding implementation, but it's very easy to write and test short scripts which have finite timing – it's an aim to make it simple to use by writing, running, and tweaking scripts.
In SAU, most data (including audio) can only be held when specifying an audio generator which plays. While some simple things are simpler in SAU (including playing with modulation types), expressiveness drops beyond doing individual sounds. Furthermore, only some varieties of synthesis are supported.
In SuperCollider, a most basic thing, generating a sine wave, looks as follows. Note that it doesn't actually play it, which requires a few additional details.
SinOsc.ar(440, 0, 0.5);
In SAU, the closest-looking equivalent is:
Wsin f440 p0 a0.5
By itself, this is a carrier oscillator which will play for the default time of 1 second. It could also be included in a list of modulators, and will then be linked to a carrier and play when the carrier does.
| Software | SLOC |
|---|---|
| saugns v0.4.0d | 7,546 |
| ChucK v1.4.1.1 | 135,348 |
| RTcmix v4.3.2 | 139,824 |
| csound v6.18.1 | 227,511 |
| SuperCollider v3.13.0-rc1 | 1,165,836 |
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.
.