saugns: cli audio synthesis on *BSD

joelkp

saugns is my cli parser, player, and WAV file writer for whatever its SAU (Scriptable AUdio) script language evolves into. Currently, it's a flexible tone generation language supporting modulation techniques, but lacking in both some audio quality niceties and enough expressiveness for musical purposes. The program is written in C99.

Back in 2011 I used DragonFly when starting it, though it now builds with a simple make following download on any of the 4 major BSDs, and also on Linux systems with GNU toolchain and libasound2 installed.

It's now 3 years since I revived this old hobby project, though for the most part, there's been little interest in it - but there's not many places where people are generally interested in such stuff. The most interesting aspects here may possibly be the minimalism, *BSD support, and some ISC licensed code in an otherwise LGPL'd program.

(Usually, I don't get any feedback at all on the program or language when posting about it, though it's a tricky niche thing to get any comments, even critical ones, about. Even vague ideas or impressions could be interesting; from how the cli works to how the script syntax looks, I've been vacillating a lot while thinking about experimenting on.)

The audio playback support is for Linux and *BSD (though the NetBSD support is still using OSS). ISC-licensed code for ALSA, OSS, and sndio can be found in the player/audiodev* files. (More could be added for other APIs in the future, though I hope to make it fit keeping it simple and no-configuration.) The Makefile simply checks uname -s to decide what to link with (with OSS as the fallback), currently good enough for "Linux" and the 4 major BSDs.

I only have x86 and x86-64 machines to test on, but other 32-bit and 64-bit little-endian platforms may work without the need for changes.

flfederation

joelkp I am a fan of the whole idea of scriptable audio in general, as well as obscure (new) languages that few people know yet. In fact I have worked on teaching programming by helping people create their own programming languages.

Looking at drumlike_repeating I feel like this language looks extremely straightforward. I don't know exactly what it means, though I feel like it would be easy to guess and almost as easy to learn to use. Of course I hope it will move to a new repo at some point.

The most interesting aspects here may possibly be the minimalism, *BSD support, and some ISC licensed code in an otherwise LGPL'd program.

ISC-licensed code for ALSA, OSS, and sndio can be found in the player/audiodev* files.

^ More things I like. Simple and no-config are things I appreciate as well; no config file for awk either.

nia

hey, interesting program.

https://github.com/saugns/saugns/blob/master/player/audiodev/oss.c#L23

please use /dev/audio. /dev/sound preserves state and is intended for use in e.g. scripts that can't use ioctl. a program can pause the device and then yours won't output anything.

joelkp

nia I changed it in the "new" branch, which will become the next version. Thanks! (Edit: Now in "master" too.)

joelkp

flfederation

Looking at drumlike_repeating I feel like this language looks extremely straightforward. I don't know exactly what it means, though I feel like it would be easy to guess and almost as easy to learn to use.

It's still very oscillator-centric. Most of the text in current scripts consists of creating oscillator instances and setting parameter values for them, or changing their values later. That script sets up connected oscillators in such a way that when they simply keep running, a drum-like sound repeats itself. Experimenting like that can result in a wide variety of sounds emerging, but with modulation it can be difficult to predict how things will sound in advance.

That sound is not a good synthesizer drum, though much better may be possible using the same basic approach. By contrast, a reasonable language for more typical FM synth drums - and many other sounds - would require, as I still plan to do, to add features for ADSR envelope and inserting repetitions of earlier-defined sounds.

Of course I hope it will move to a new repo at some point.

Actually, the repo is already also on Codeberg. I've not moved the website which basically marks which host the project is more linked to. Still vacillating on where and how the site should be, but it's simple enough to move it whenever it happens.

Simple and no-config are things I appreciate as well; no config file for awk either.

Some time after reviving my old project, I was wondering whether keeping it this simple was good, or whether that was doomed to be broken and I was missing something everyone else undestood, and should follow the modern conventional wisdom instead. Then I read Poul-Henning Kamp's article, A Generation Lost in the Bazaar, on how the conventional wisdom is simply a culture of mindless copy-pasting, and how going against the grain of that is a great thing.

flfederation

joelkp

conventional wisdom is simply a culture of mindless copy-pasting, and how going against the grain of that is a great thing.

This is a gem. I am going to copy-paste it everywhere. Jokes aside, I love it. And I hope you'll ultimately go with Codeberg or Sourcehut. I use Notabug, so I have no horse in the Codeberg / Sourcehut race. I don't expect anybody in this thread to think the repo is important, but you are thinking about it so I mentioned it twice now.

I figured it was an oscillator-based setup. I have more experience with sample-based production (only a little) and that's how I would do it, but I've played with oscillator-based synths and not only are they cool, they would be even cooler if I really knew what I was doing. Not so foreign that the syntax isn't fairly straightforward though. I doubt it would be tedious to use what you're setting up.

I like DSLs more than most people. For this purpose, maybe people will say you could just write a library. And you could. The question (IMO) is, would there be a benefit to it having its own syntax? I think that argument isn't made quite often enough. When you're dealing with large amounts of specific kinds of data, I don't think it's such a wild-eyed notion that sometimes readability or intuitiveness is aided by a syntax designed for that purpose-- especially if it doesn't get too complicated.

Most of the complaints people have around DSLs seem centred around corporate processes. Expecting corporate processes to make a lot of sense to people seems like an exercise in futility. This seems more like an exercise in fun and art, good luck with it.

And keep questioning conventional wisdom-- some of it is useful, but it is often given more credence than it is due!

joelkp

Some current thoughts on the language...

I'm unsure of what I really hope to do long-term. When starting out, I deliberately didn't look too closely at the most popular alternatives, and instead saw how far early personal inspiration went. I've become bored with some of my old ideas, but not yet figured out what I really want to extend capabilities towards.

There's several established alternatives, mature and varyingly similar, but not quite the same thing as my project. Big names include:

csound provides an assembly-looking language, with scripts divided into two parts ("orchestra" defining instruments, "score" defining sequence of use). Has grown since '86 to provide very general functionality. (A relative descended from a '78 program, now RTcmix, used only the "score" part while adding an early C-like scripting syntax extension to improve expressiveness.)
SuperCollider, launched in '96, has likewise developed to provide very general functionality, but with a C-family-looking OO and functional language.
ChucK, since '03, looks somewhat C-like and is more minimal, and is mainly set apart by its approach to timing and concurrency.

Back in the 80's, programs in the general genre were mainly to render audio data from scripts without interaction. Later, "live coding" with "real-time" programs became prominent, and both the popular old programs and new ones are now often (re)designed with that in mind. By contrast, I still have in mind the older use.

Newer languages of this kind seem to often follow functional and/or OO paradigms. (But some "live coding" languages have unique esoteric terseness.) There's also more general languages for audio development reflecting that, like Faust and SOUL. I hope to make something a bit different, intuitively a language for composing complex tracks grown from a simple start. It may or may not progress for real.

Some planned and possible changes

What features to offer? The syntax could be extended in the direction of function abstraction, e.g. by making lists of things work like functions without parameters when referred to, and then extending that by adding parameter-defining. Syntax could also be extended in the opposite direction, towards handling the output of sound generators more generally and allowing doing more with audio outputs, e.g. adding effects/filters taking audio input(s) and producing a new one.

But the language still wouldn't be Turing complete, and the program wouldn't provide a full-featured toolbox for all general uses. I'm however, like many, interested in simple building blocks that can be combined flexibly with a large range of results. Maybe after some unknown number of years, I'll figure out some new way of doing audio synthesis, complementary to older ones. Or not. The vague sense that I haven't hit upon what I look for yet may lead to something, or to nothing, in the end.

A git branch, old-dev_202006, contains a reworked version I forked from a simpler 2011 starting point. It adds a noise generator, N (with white noise added using Nwh), and when added back to the main program - some redesign ideas are carried over first in rough order of increasing size - the wave oscillator will be re-renamed to W instead of the current O (so a sine oscillator will be Wsin instead of Osin).

(What are those big letters, really? I clarified that to myself: class names, but the language only offers pre-defined classes for creating instances. The type or mode label, such as sin or wh, is like a constructor argument. Both classes support changing those types later for an instance, making those types a bit different from conventional sub-classes.)

A not-yet implemented idea is a parse context nesting syntax which works with timing offsets, and can perhaps also be combined with a kind of linkage/inclusion connective. The idea for the connective is to allow linking all members of a list to another list, by writing it between the lists. If the nesting syntax is used to enter a subscope before the connective is used, closing that subscope after the second list would return the parsing context to before the connective was used, so that other things can be done in relation to the first list. (This syntax idea, sketchily described, is meant to allow to build DAGs rather than just lists, while keeping a terse and simple-enough syntax, which is an old to-do.)

I think conventional wisdom may be most needed in redesigning the audio generation end of the program, turning it into something that handles lists of simpler instructions to fill and use buffers in various ways. The use of an oscillator can involve a number of buffers, and translating into lower-level instructions will increase the number of instructions rather than remove the need to deal with oscillators, say, yet such a splitting to work out input/output dependencies first and do the rest later seems like the next step to allow the language to become more flexible.

joelkp

A year and a half later, I've not yet extended language features much, except numerical expressions for parameters which are evaluated at parse time, which now have a little collection of math functions. So now, as a new one-liner example on the website shows, randomized scripts are possible (given seed(x), time(), and rand())... I've also worked on trying to make a better page about the language.

Well, more interesting in relation to *nix tools and their use in general may be that I added command-line options for audio data over stdout. Now, for example the "sox" program can be used together with mine to write files in more formats without needing temporary files. It seems popular to pipe WAV files, but that's broken, since the header will be invalid because size was not known and only some programs handle that gracefully and some still warn when they do. Instead, I implemented AU file support (I corrected the Wikipedia article after running into its previous inaccurate info about the header) and use that for -o- output, but still WAV for other (named, not -) output files. I also added an extra option for raw data to stdout.

I tried to run some programs in parallel with mine through piping, including to produce visualizations like spectrograms in parallel with audio output. It works well when the other program is fast enough that stuttering is avoided. I don't yet know of any truly good open source option for that, though, unfortunately.

To add to the old tangent on git and web hosting: I've kept the website on GitHub, while placing the git repo on both Codeberg and Framagit, and linking there too. Ultimately, I'm not entirely happy with any web git UI I know of, and I think the worst thing about Gitea (hence also Codeberg's UI) is that it imitates GitHub too much. I think core git features are featured too little (and also displaced too much by other inventions). But the GitLab software used on Framagit at least offers a page dedicated to each plain git tag, showing its message and options, so I link to those on the website.

joelkp

Late last year, I came up with a new type of sound generator -- or relatively new. Value noise is old, common in graphics, sometimes used in audio. But I've never elsewhere seen a value noise generator which supports FM & PM, i.e. as carrier and not only as modulator. Maybe I missed it (it's obscure but not new), or maybe I invented it by combining the two types of features.

Anyway, there's now some drums and other sounds on a new examples page using it, though many of the sounds using the new R generator use it as modulator only, and not as carrier. On Mastodon, I also put a simple soundscape (audio) which uses it as both:

'f=10/3
Rcos mg f$f t60 p[
        Wsin r10 a4 p[Wsin r-2.r+2[Rlin mt p0/4 f20*$f]]
]

The online examples are incomplete relative to those I have with the program (apart from the drums), which in turn were pretty quickly made while testing.

My program and language are still awkward and limited for general musical use -- but now they're better for soundscapes, and allow for randomized pseudo-melodies created by very short scripts.

Compared to other uses of value noise, I also added more noise types, including a few unusual ones -- I found no search results for violet binary noise (my version of which never repeats more than twice in a row), which seems nifty for pseudo-random drumming (but not the only way to get a similar result). I also use a collection of line types I'll add further to as options for how to connect the pseudo-random samples produced at the current frequency. More mixtures of noise and polynomial shapes may be interesting as such an audio "paintbrush" for noise within noise. I've written more on my related PRNG side-project in a WIP article series on my blog.

joelkp

I missed a bug (not properly fixed yet, but there's a Makefile change workaround) for seemingly any amd64 clang builds. (I had tested gcc amd64 and clang i386, but not clang amd64.) That example script I shared above will sound different (broken) on any buggy build, as also mentioned in the linked bug (it's the same script as examples/sounds/bg-scape-00.sau).

joelkp

joelkp I fixed it but I don't understand why the fix works. I replaced a little integer sign bit fiddling arithmetic with another expression that should be equivalent.

rvp

joelkp I replaced a little integer sign bit fiddling arithmetic

Shift operations on signed int types can become undefined, can't they (esp. fiddling with the sign bit)? Better use uint32_t everywhere for the intermediate calculations. And, also force any constants (eg. 1) to be unsigned too: 1U<<31 since they're also signed by default.

Compile the code with -fsanitize=shift or -fsanitize=undefined to catch these sort of things during testing.

joelkp

rvp That was it. I'm now making some more changes, after testing (good suggestion, I hadn't used such test builds before -- with it my make fullcheck silent run through all my example scripts gave a full list of locations in the code to look at).

In the next version I'll change all the -fsanitize=shift items (all were in that one new source file), though the result is the same for now after the first fix. But I'll otherwise keep using the signed integers in those particular functions (which -fsanitize=undefined complains about), to avoid having to add lots of typecasts and/or temporary variables to keep divisions (right-shifts) and int-to-float conversions working the same. That stuff in C is a bit of a pain. Technically the signed overflows in there not from shifts are then UB, but the latest C standard brings a little sanity by making those operations two's complement in the way generally expected, so that seems non-risky.

joelkp

joelkp Finally, on that old bug and fix last year, I redid the fix shortly after, deciding to follow the advice on avoiding signed ints in some kinds of code given their UB. To ease the pain of more typecasts etc. (when signed values are needed, for e.g. conversion to float) I made use of the one saving grace that the C language has, macros.

While I'm getting more tired of programming in C, as of late, I'm recently learning how to make it a little less clunky doing further things with the preprocessor in various ways and places. And it seems there's a boom of people trying to make C nicer by going further than myself in that regard. Problem is, what fits a program depends on the specific code it needs, so I'll need to try more of that over time rather than reuse their stuff.

uxer

there's been little interest in it
Usually, I don't get any feedback at all

Have you heard of https://sonic-pi.net/ ?

Sonic Pi uses generated beeps and pre-recorded sounds, applying effects to them.
If I understand correctly, saugns doesn't work with pre-recorded sounds,
so the comparison isn't quite honest.

Still, it is the approach that I like:
At the very frontpage Sonic Pi offers enticing examples - short and elegant code producing rocking audio.
Having downloaded the app, the built-in help is extensive and no boring, guiding you from first steps through all the goodies it has to offer. And not requiring music theory knowledge.

A newcomer knows from the beginning how cool can Sonic Pi be and advancing is a pleasue.

lacking in both some audio quality niceties and enough expressiveness for musical purposes

Whatever, almost every project out there is incomplete, in-progress, under construction etc.
I see saugns has potential. But having compiled and listened to examples I am not sure whether I want to invest efforts and go further. I like some examples like rainy_thunder, bg-noise*, cat-purr, music-elem*, voicelike*, wooddrum, defaulttime*, panning, tone_seq-v[1..4], drum-cat-rand[1..2], drum-sin and random-drumming1. Quite some. But I don't know what else and how much more can I get from saugns. Most example demos sound like, well, demos. I would welcome less demos but more finished compositions. Something exciting, that a user might want to set as his ringtone or humm to or dance to. Or want to produce his own composition on par with what he just heard. tone_seq-v[1..4] are the closest. A real tune! How about adding drums, voicelikes, purr etc. to produce a composition?
Spark interest among would-be users!
Compositon script code would also provide an advanced reference.

SAU language first look impression:
Sonic Pi looks tidier, SAU looks noisier.
Like ruby/python vs c/sh/perl.
I have a hunch that most musicians, even coding ones, are not that techy and would prefer a cleaner-looking code.
I personally prefer less typing, provided that the result is legible. And I am in favor of symbols like $*#^& and more - I find APL one of the prettiest-looking languages.

joelkp

uxer I didn't visit and see this for some time, but thanks for some honest feedback. It's true I don't have much in the way of music among my current audio examples. I've made some simple tracks, but they sound more like something that may fit a 90s video game, and not with enough to them to want to rock out to. It seems like you've already checked out the 'extra-scripts' repo given scripts you mentioned, and in there extras/bg-scape* have a few of the one-liner algorithmic kind that has a bunch of things connected for modulation, playing out a few rich sounds in notes outside the 12-tone scale. So, for now only demos.

I'm not surprised you find Sonic Pi better for musical purposes. Apart from the use of samples, it also has higher-level constructs in the language compared to in SAU. My language doesn't yet have a loop construct, for example, but bounded loops are among several things planned. I'm considering other ways to insert structured repetition and variation as well. That's the main gap where I think my language still sucks, and my long-term focus is on adding new features and syntax. Another gap is the lack of being able to add echo, reverb, and such -- effects being another later to-do, and a key ingredient in the compelling examples in Sonic Pi, and other systems too, is being able to just plop a reverb onto stuff.

Right now, the best practical use for music of my program is probably to use it to make samples, and then use these samples in some other program or system.

I think the lower-level things in my language, the audio generator types (now 3, with v0.4.3 released this week) and their basic use, is concise -- but those are still basically all. I've explored how randomness can make simple musical sounds and variations, now, and want to move on to adding non-random patterns, making that simpler. Pattern signal generator is another idea I toy with along with loops, with its own syntax and/or to have an array or list of values to be provided in a script -- used somehow, then the result is linked to other objects which run accordingly. (For example, generate a stream of notes for a duration, controlling other generator(s).)

We'll see what ends up done over the next years, or however long I stick to this. Right now I've prepared to do further redesign of my program.

uxer

joelkp

While I'm getting more tired of programming in C, as of late, I'm recently learning how to make it a little less clunky doing further things with the preprocessor in various ways and places. And it seems there's a boom of people trying to make C nicer

Offtopic, but since you mentioned it.

https://github.com/tavmem/buddy

An extreme example of contrasting styles is contained in file a/b.c. There are 2 versions of the buddy memory allocation system. The "ATW_VERSION" has 11 lines. The second is in well documented traditional C (almost 750 lines).

The code in a/b.c is tuned for Solaris on Sun workstattions. It undoubtedly needs modification to work with Linux or Windows or macOS on Intel processors.

https://github.com/tavmem/buddy/blob/master/a/b.c

From the link above - this is one of the most beautiful code I've ever seen:

#include "k.h"
I MZ[31]={1};Z I *MM[31];mi(){MZ[7]=MZ[13]=MZ[19]=MZ[25]=2;DO(30,MZ[i+1]+=MZ[i]*2)}
Z mmr(n,i){if(i<18)i=18;R err(2,n),tmp((MZ[i]+2)<<2),1;} /* Dan MZ[i+1]? */
C *mab(m)unsigned m;{I *p,*r,i=2,n=m;for(n=(n+3)>>4;n;n>>=1)++i;
 do{if(p=MM[i])R MM[i]=(I*)*p,(C*)p;for(n=i;n<30;)if(p=MM[++n]){
  for(MM[n]=(I*)*p,p[-1]=i;i<n;)r=p+MZ[--n],MM[r[-1]=n]=r,*r=0;R(C*)p;}
  if(mc()>=i)continue;} while(mmr(m,i));}
I *ma(m){R(I*)mab(m<<2);}
mf(p)I *p;{I i=p[-1];*p=(I)MM[i],MM[i]=p;}
mb(p,n)I *p;{I i=31,j;for(n-=2,++p;i--;)if(j=MZ[i],j<=n)n-=j,*p=i,mf(p+1),p+=j;}
mc(){R 0;}
I *mz(){Z I b[31];I *p;DO(31,for(b[i]=0,p=MM[i];p;p=(I*)*p)++b[i])R b;}

Mastering this style is on my todo list.
I like having the whole program at a glance, instead of scrolling pages and pages.

You say there's a boom. May I ask for links? Especially for C89 🙂

joelkp

uxer
Interesting-looking, though not exactly what I'm looking at currently.

You say there's a boom. May I ask for links? Especially for C89 🙂

Maybe "boom" is a bit hyperbolic. Anyway, it mostly revolves around the C99 preprocessor (the iceberg), which makes it possible to do much more by combining macro constructs in clever ways. Recent are the Rust-inspired datatype99, and underlying metalang99, libraries. These use a more heavy-duty variation of the map-macro technique (near a decade old), which allows for a macro that takes each argument and applies a supplied macro to it, and much else. The preprocessor is "practically Turing-complete", but with a limited maximum number of scans (4K) instead of a limited amount of memory.

So far I use the old X-macro technique instead of map macro, as it gets the same job done with fewer and simpler supporting macros. But it looks a little clunkier, and you end up having to repeat names a few times to use it, so I'll switch if I end up with much more X-macro style stuff. I've increased use of X macros as I've found more places that benefit from it. I've experimented with other stuff in other code, but not needed it in my main project yet.

It's my impression that knowledge of what can be done with the preprocessor has built up over the years, and now that it's more complete and lots of people are flirting with newer languages, there's more people trying to bend C into a nicer shape by being clever. Another bulky library collecting a bunch of tricks and going back further is P99, by a C standards committee guy.

Basically, my challenge is to figure out what kind of stuff is actually useful for my purposes. I don't use any general library for these things now, I prefer to only add what's really needed. But if I find there's a point to some done or not-yet-done syntactic sugar, it probably can be implemented somehow with enough macros.

joelkp

Now SAU scripts can finally take command-line arguments, in v0.4.4 out yesterday. Maybe quite overdue as "scriptable audio" is in the name of this project (first planned 2014, more ideas later). It was quick work to get it working, I just hadn't bothered before.

Two language constructs allow checking for passed values. $variable ?= value is pretty conventional for non-overriding assignment. $?variable to check for a variable being set and error out with a usage notice if not, is something I haven't seen elsewhere. (There's deliberately no print feature in the language, so messages from the parser are how to get a usage notice.)

Apart from making testing easier, these features may currently mostly help people write scripts to make weird noises. Later features may allow more, like using this to specify how many times something in a musical script should loop.