aeolus: use aeolus-stops; aeolus-stops: init at 0.4.0

[orivej]

Description of changes

This makes aeolus useful out of the box. Without stops it has no instruments. From its readme:

---

"3. Binary packages

This release permits packagers to install a working Aeolus without touching a users's home directory, as follows.

• Install the aeolus binary in /usr/bin and the two plugins in /usr/lib.
• Install the stops directory in /usr/share/Aeolus.
• Install this README into /usr/share/doc/packages/Aeolus.
• Create the file /etc/aeolus.conf containing:

# Aeolus default options
-u -A -S /usr/share/Aeolus/stops-0.3.0

This will use the default instrument 'Aeolus', and save the presets in .aeolus-presets in the users's home directory."

---

-A forces ALSA, and thus is not enabled in our package.

Aeolus starts up faster when stops are installed in a user-writable directory (and the user presses Save in aeolus), but this writes about 50 MB of wave files; so using a system-wide installation to save space is a trade off:

---

"The waves directory will be empty initially. When Aeolus starts up, it will compute wavetables, one for each pipe. This is indicated by the flashing stop buttons. The same will happen whenever the tuning or temperament is changed. These wavetables can be saved (so Aeolus will be ready for use much faster next time), but only if the stops directory is writeable for the user. This will not be the case for a binary installation as the stops dir will be system-wide (e.g. /usr/share/Aeolus/stops-0.3.0).

"In order to be able to save wavetables or edited stops the stops directory must be copied to a location where it can be modified by the user, (e.g. ~/stops-0.4.0)."

---

This is based on #223089 and is made into a separate PR because the changes I wanted to propose were too many. /cc @Rampoina for review

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.05 Release Notes (or backporting 22.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[Rampoina]

The changes look good thanks, I'm new to nix so I expected some things to not be idiomatic.
Maybe next time you could use my commit directly or ask me to change it here though. (Same goes for the other 2 you changed)

[orivej]

Sure, but the case of aeolus was a bit tricky, initially I could have only written what I'd like to change, not how to change it. I had to iterate over a couple of different approaches until I settled on this one. At that point submitting a new PR was easier than describing the result.

Meanwhile the suggestion for #223103 was easy to make, so I did not implement it myself. Would you like to finish that PR?

[Rampoina]

Yes, I'll finish that one but not until friday.

[Rampoina]

@orivej Just to be clear I don't mind you doing it by yourself although I would have happily fixed anything in a normal review process. What I do mind is creating a new PR from scratch instead of editing mine yourself or PR against my fork or any other way that keeps the commit log intact.