26 Home
Joel K. Pettersson edited this page 4 months ago


Notes in addition to what's on the project web site.


For new versions, SAU language changes that may require adjusting one's own scripts are mentioned in the tag messages and also summarized here. For example, if a wave type is renamed, then some searching and replacing may be needed.

Changes have ended up curiously layered: the released v0.3.x saugns versions have a history in which changes often move down to the evolving untagged v0.2.x sgensys versions (on top of the older 2012 snapshots once released at Gna!). This may be because the old vision for "sgensys" as a simple program can still be worked towards until complexity grows and code is reorganized differently. The features and the "SAU" language are still developed quite incrementally.

Old plan

Future versions after v0.3.x rework the code from a simpler 2011 "mgensys" starting point (re-using various smaller modules and debugged parts from the v0.3.x history).


The scripts in examples/ show how various things can be done. Some in devtests/ also do, but others have different purposes, e.g. parser tests, or sketching out ideas for further development.


From early very vague ideas, over time some things have come into focus since the project was resumed in late 2017. More ideas may develop later, and comments are welcome.


A main focus for v0.3.x versions, with bugfixes, basic design improvements, simple audio quality improvemets, and various little tweaks to the SAU language to improve usability.

Further features

An old idea is to add new signal generators to the SAU language. Ideally not so many, but each making for a flexible and powerful building block. Newer ideas include variations on how to use noise (random numbers). Planning is still quite open here.

More flexibility to the SAU language, to usage of the current audio generation building blocks, is another area where ideas develop over time, and small improvements often seem obvious in hindsight. Relative to other ideas, this seems to involve intermediate redesign steps.

Other features which would need extending the audio generation end of the program more include ADSR envelopes or a more flexible alternative. (Other envelope ideas are also welcome, as ADSR doesn't cover everything.) Unlike the old ramp feature, they could e.g. link to time to re-trigger, for easier re-use in a script.

More abstractions for sound re-use in script after definitions could also be developed part by part.

New language?

Originally, the idea of a new language came from not seeing a way forward with the old. Some kind of SAU v2.0 which looks and works significantly differently could still end up a worthwhile idea later on. It remains to be seen what can be built on the old foundation with more knowledge and inspiration, and it's not easy to know what's worthwhile to do later.

Mainly, it could turn out that there's basic limitations worth moving past with something new. But what would be built, then? Some kind of more mature and full-featured SAU v1.0 may provide ideas, if not a more definite goal.