Bring4th

An old project of mine, resumed in late 2017, is saugns, which parses, plays, and/or writes WAV files for SAU scripts (SAU is the audio script language defined by the program).

It's a command-line audio program for Linux and *BSD. Apart from timed tone sequences (with various wave types), the program supports amplitude, frequency, and phase modulation. (PM is what is actually at the heart of the 16-bit video game era "FM synth" sound; in the 80's, Yamaha changed FM into PM but called it FM.)

(For somewhat less technical Linux users, a C compiler, e.g. "gcc", and the "make" program, and the ALSA "libasound2" library, need to already be installed on your system to, well, be able to make the program from the downloaded source by running "make" in the directory. On Ubuntu and similar, "libasound2-dev" is needed, as needed files are split into that package.)

There's actually two related programs, temporarily. The current main version is saugns v0.3.6e, and what you get when it's downloaded. It has the most features, except being all about wave oscillators and what can be done with them. A partial rewrite, with a white noise generator just added, is based on an older version and still lacks "ramps" (smooth, timed parameter changes). The redesign-in-progress is in the "mgs0.1" git branch; if the program is downloaded with "git clone", then a "git checkout mgs0.1" afterwards in the directory will switch to that version.

The main version is described on the web page, along with the included documentation and example scripts. The redesign-in-progress version only has its README file for now, along with a smaller set of example scripts.

I have the vague hope that the new version will lead to a scripting language actually suitable for writing music in, though neither version is there yet. The current versions make for easy experimenting with sounds, but any repetition requires full copy-pasting.

You could make a plugin for Audacity. That way you can work with the whole Audacity library.

I try to minimize dependencies on external libraries, and keep it as minimalistic as possible. Otherwise, had I done it more pragmatically, there would be a variety of libraries to look into.

Are you wanting to build a large audience who uses your app?
Or is it a hobby?

I think it will remain smaller, though I hope it will find its uses for others as well. Popularity is not a main concern, but I hope some may follow if the basic ideas and design develop into something generally more useful.

There already exist other "music programming language" programs, e.g. csound and SuperCollider, which are much more feature-packed. Much of the whole point of making your own is to go about the language differently.

The language I came up with so far is very short and simple for the simplest things, but way more limited. (I have some ideas for making it more expressive, but there's much I'm still undecided about.)

Ideas or feedback about the language is very welcome, but in part it's the trickiest thing to "invent". Once the ideas are there, the trickiest thing becomes making them work as elegantly as possible, without greatly growing the size of the program. Then comes smaller parts of how the program does this or that, where various options exist (and some stuff will no doubt be done better in this or that program or library).

For a simpler answer, it's a hobby, though it remains to be seen what may grow out of it.

Actually, I'm not sure why it matters to me to the extent it has. But while feeling rather down, in part, the last years, I've worked on it in a kind of obsessive-compulsive rut.

Something has, however, kept me back from working the ideas I already have into it. This seems to gradually give way this year, as I work on the redesigned version.

(04-04-2020, 10:31 AM)Great Central Sun Wrote: [ -> ]You could make a plugin for Audacity. That way you can work with the whole Audacity library.

Actually, an input plugin for Audacity is not a bad idea, later on. That would allow loading a script without having to separately turn it into a WAV file first. But I wouldn't like audio generation to depend on Audacity (which may be able to provide a few things in that area).

Why is depending on Audacity for audio generation a bad idea? It's a pretty solid and tested product.

Simply because it's meant to also work by itself, and if turned into a library, it should also be usable in programs which are unrelated to Audacity.

I have been thinking of splitting most of the program into a library at some point. Input plugins for media players would also be interesting to make then (so scripts can be added to playlists).

For now, there's just the command-line program, with an interface similar in style to a compiler (which is basically the simplest type). Good for testing, or playing scripts without further interaction. But neither like a media player, nor usable for "live coding" (writing and running things as each line is written). Some people use "live coding" music languages for music performances.


But first, working on the language. The next thing I plan to add is a way to group things and keep them from "playing" where placed in the script. Then they can be inserted to play later, and this can also be turned into a simple way to repeat sounds.

Well, I don't know how much interest and discussion there could be regarding the more intricate things on a forum like this, since it's fairly specialized.

To update a bit, 8 months later: What I planned to do is still in the future, though other aspects of the software design are becoming a bit clearer for me. The website has a new part about the design (in addition to the old about the language and using the program). For the needs of future discussion (wherever it may take place), I'm trying to bridge the gap to more easily understanding the main ideas behind it all, in a short and hopefully clear text, which gradually becomes more technically involved.