fixed weird jack incompatibility and added some more synths

.prettierrc.json

@@ -0,0 +1,8 @@
+{
+  "tabWidth": 2,
+  "printWidth": 90,
+	"useTabs": false,
+  "proseWrap": "always",
+	"endOfLine": "lf",
+  "embeddedLanguageFormatting": "auto"
+}

CONTRIBUTING.md

@@ -0,0 +1,251 @@
+# CONTRIBUTING
+
+## Tldr
+
+**Do's**
+
+- Be concise
+- Follow the [Formatting Rules](#formatting-rules) to the best of your ability
+- Segment larger changes into managable, reviewable commits
+- Leave a trail of your development so I can tell you put some effort in (doesnt really
+  apply to smaller commits)
+- Write your own code
+- Leave some way of crediting your work
+- Disclose the capacity in which you used AI. Most of the time, anything more than making
+  examples or helping you understand the codebase will be disallowed. As little AI code
+  should make it to production as possible
+
+**Dont's**
+
+- Report upstream issues to me (ie an issue with the app itself, not my config)
+- Make major structural changes
+- Submit chore commits such as updating the flake, I can do that myself
+- Add new hosts for no reason, make your own flake and import the modules you want for
+  your host
+- Majorly change existing hosts for your own preference
+- Ask AI to fix your issues and expect me to merge changes
+- Delete existing modules. Executive decisions like that will be made at my disgression,
+  and will be done as non-destructively as possible, such as moving those modules to a
+  "deprecated" branch in the future.
+
+## General format
+
+All emails regarding this repo (or another) should have a subject prepended with the
+following:
+
+```text
+[GIT] [voidarc/nixos] (request type)
+```
+
+The content of the second set of brackets should be replaced with the specific submodule
+or repo that is being referred to. For example, in the case of a quickshell bug, it should
+contain `voidarc/quickshell`.
+
+In general, for most requests, I also implore you to include a github username (or
+equivalent, codeberg, gitlab, etc.) so that I have a frame of reference for you as a
+person, and also so that you can be credited in any resulting commits. Depending on
+scenario, this requirement can be waived, or substituted for a reddit account or
+something.
+
+The third set of brackets pertains to the subject proper, and should only reasonably
+contain `issue`, `patch` or `feature`. If you believe that your request does not fit into
+any of those categories, then feel free to do whatever you want within reason.
+
+## Issues
+
+Issues are restricted to bugs or otherwise not fixed problems in the code. If it is an
+upstream bug, ie one not caused by my specific config, please don't send me a complaint
+about it, refer to the source app. The subject for an issue should be formatted as such:
+
+```Text
+(prefix) (module type) (specific module) - (description of issue)
+```
+
+The prefix shoud be formatted as above. In the case of an issue pertaining to another
+repo, the module type and module name may be omitted, unless it is an issue with the
+dendritic module implementation, in which case the repo in the subject should be this one.
+
+The module type should match the repo's folder structure, being one of `feature`,
+`system`, `attr/attribute` or `host`. Self explanitory. Doesn't have to be an exact match.
+
+The specific module should be the name of the module itself, not just the directory that
+contains it, due to the fact that some directories and files contain multiple modules. In
+the case of a file containing both a package and a module, favour the module that
+implements the package, and not the package itself (`self.nixosModules` rather than
+`self'.packages`).
+
+The description should follow standard conventions, as you would report on other
+platforms. Don't make it stupidly long, common sense required.
+
+The body of the email should be reminiscent of a github issue, and contain the following
+items in roughly the presented order:
+
+- Clear description of the issue (and why it's an issue in the first place, and not
+  personal preference)
+- Step by step instructions on how to replicate the given issue
+- Step by step instructions detailing what you believe the behaviour should be
+- Any attempts to fix the issue, or references to suspected code that may be causing the
+  issue
+
+If you have attempted to fix the issue, or altered the code, please refer to the next
+section
+
+## Patches / Contributions (Pull requests)
+
+Patches are for altered code that you would like me to review and possibly add to the
+codebase. Most of the time, these should be for issues that you have encountered using the
+repo, not new features entirely. If a patch doesn't fit an issue, is mostly or fully AI
+generated, or otherwise doesnt fit the repo, it will be rejected.
+
+The format here is similar, but with a few key differences. The type of request should
+obviously be patch, and the rest should be identical to the previous type, containing
+module type, name, and a short description of the issue.
+
+The body should also follow similar beats, having a breakdown of the issue and detailing
+the intended behaviour. Beyond the detailing portion, there are some other specific things
+that are required for issues in particular.
+
+- A description of whatever alterations have been made to the code
+- Some form of username so that, in the event of a merge, you can be credited properly
+- A disclosure of how much or little AI was used in the creation of the patch. For
+  completeness, even if no AI is used, please include "No AI was used" anyway, it is not
+  implied.
+
+A git patch file should be attatched to the email, not a link to a github repo or
+something else. Any "patch" email with no attatchments will probably not be looked at any
+further than the issue section. For patches, please refer to the
+[Formatting Rules](#formatting-rules)
+
+Both issues and patches are on a first come first serve basis. Because there is no public
+forum (I'm sure as hell not maintaining one), if someone submits an issue or patch, even
+if someone else independantly discovered the bug, the first person will most likely be
+credited for that issue.
+
+If you have previously opened an issue, and wish to make a patch for the same issue, reply
+to the initial issue email, and prefix the subject with `PATCH:` instead of the usual
+`RE:` or whatever your email client chooses to prepend. The rest of the subject should
+remain the same. The email should then contain the patch-specific sections, found above.
+Don't bother re-iterating the issue.
+
+## Feature Requests
+
+Feature requests are for anything that doesn't already exist or doesnt otherwise fall into
+the previous categories. These are more freeform, and could come in the form of a useful
+app, a better way of managing something, or a better replacement for something that is
+already in the repo. Most importantly, this is NOT somewhere to shill an app you
+vibe-coded. Any AI generated apps will be rejected out of principle.
+
+Headers should follow this structure, but, again, this is lenient:
+
+```text
+(prefix) - (Feature type) - (App name): (description)
+```
+
+The feature type, as before, should be one of the given folders in the repo. Generally,
+this will be a `feature` for a new app, but could be `system` for a new driver or
+`attribute` for a new collection of packages. If it is more general than any of those
+categories, or smaller in scope than an entire feature, use the feature type `other`, and
+detail what you are requesting (other should be used if you are just requesting a singular
+package be added to the system, for example).
+
+Instead of following a fixed structure for the body, it is up to you to make a case for
+whatever you are suggesting. Whatever that entails is up to you. It could be use cases, it
+could be reasons it is better than whatever I am using. Be as verbose or as minimal as you
+wish, but keep in mind that the better your argument is, the more likely I am to accept
+your contribution. Again, if you wish, you can leave a username so that you can be
+correctly credited if I decide to include whatever you suggested.
+
+If you are suggesting a new feature, app or otherwise, you may also choose to make a basic
+or full module implementing that feature, and then attach that to the email in the form of
+a patch. Refer to the [Formatting Rules](#formatting-rules) for further instruction on how
+to write your code.
+
+Please also leave references for whatever it is you're suggesting, not just the name of
+the app. This could come in the form of documentation, a homepage, or the link for its
+github. In general, if an app has none of these things, or is closed source in any
+capacity, it will not be accepted.
+
+## Formatting rules
+
+Formatting in this repo should attempt to be standard to whatever I am using. For ease of
+use, either refer to or use my nvim config (`#nvim` output for this repo, refer to the
+README for how to run it). This prevents ugly git histories with commits specifically for
+formatting etc.
+
+### General rules
+
+When submitting a patch, there should be no merge conflicts with the current HEAD at the
+time of creation. It is a good rule of thumb to pull from remote before making a patch,
+incase behaviour changes.
+
+If there are commits pushed between the time you send a patch and the time it is reviewed,
+any resulting merge conflicts are not your fault, and therefore will not be treated as
+such. Don't resubmit the same patch because there are new commits on remote, when patches
+are reviewed they are inserted at the point at which they were created, not on top of
+newer commits.
+
+#### Branches
+
+All patches should be mergable to the main branch, ie not have a patch for the `feature-x`
+branch or some nonsense. I do not have your git history, and therefore don't have whatever
+branch you created on my machine. In general, most changes should be restricted to one
+commit, so that crediting is easy.
+
+If a change is more than one or two commits, make a new branch, make the changes that you
+want, then merge to the latest head before submitting a patch. When merging back to main,
+please use a merge commit instead of fast forwarding or clobbering the branch. This makes
+it easy to see who made what changes in the git history, and keeps blame easy to read.
+This merge commit will be where your credit goes. If you submit a patch that contains a
+load of commits on the main branch, the chances I accept the patch are very low.
+
+### Code
+
+There are many types of code in this repo, so if there is any confusion, either refer to
+the config that I am using in nvim, or send me an email asking me how to handle it.
+
+#### Nix
+
+For starters, all nix code should be formatted with
+[Alejandra](https://github.com/kamadorueda/alejandra). If you choose to format your code
+with nix-fmt or something else, chances are I won't refuse it, but I will overwrite your
+commits with a formatted version. To format the entire repo properly, run the following
+command:
+
+```bash
+nix-shell -p alejandra --run "alejandra ."
+```
+
+This will recursively check and format all `.nix` files in the repo, which is what I want.
+
+As a secondary requirement, try to follow the already set out conventions that are on
+display in this repo, as well as the conventions of dendritic nix. A few examples:
+
+- All top level objects should be merged into one unless there is a good reason for it
+- The first item in a module should be the module definition (`flake.nixosModules.xyz`)
+- All modules should be portable unless there is a good reason for it
+- Modules should reference eachother through `self.nixosModules` instead of relative
+  paths, which should be avoided in most scenarios
+- In general, if a package is available in nixpkgs, an input need not be added. This rule
+  differs case-by-case due to versioning differences.
+
+#### Markdown
+
+All markdown files should be formatted using prettier, with the settings provided in this
+repo. For reference, the rules are:
+
+- 90 characters maximum, excluding code blocks
+- word wrapping
+- tab width of 2, as well as replacing spaces with tabs
+
+#### Other languages
+
+For one-off config languages (think `kitty.conf`), no formatting is needed. Whitespace can
+be added at the programmer's disgression.
+
+For standard structured languages, such as json, yaml or toml, if there is an available
+prettier formatter, then it should be used. In general, tabwidth should be 2 and spaces
+should be used across the board. Don't use some esoteric formatter just to be special.
+
+For actual programming languages, like qml or lua, either use the provided formatter, such
+as `qmlformat`, with the settings configured, or refer to my nvim config (in this case I
+use `stylua` with the default settings)

README.md

@@ -1,38 +1,75 @@
 # The Void
-*An opinionated dendritic nix configuration*
+
+_An opinionated dendritic nix configuration_
 
 ## The Concept
 
 I have been trying to get consistent, across device experiences from the second that I
-started using linux. I tried my best with arch, but I foolishly believed that just remembering
+started using linux. I tried my best with arch, but I foolishly believed that just
-what packages I installed would be enough. Then I started managing my dotfiles with GNU stow,
+remembering what packages I installed would be enough. Then I started managing my dotfiles
-but that only allowed for a single host per repo. I moved over to doot, and simultaneously nixos.
+with GNU stow, but that only allowed for a single host per repo. I moved over to doot, and
+simultaneously nixos.
 
-I believed a dotfiles manager was my endgame. The final evolution, but it was far from ideal. I had to
+I believed a dotfiles manager was my endgame. The final evolution, but it was far from
-manage a mess of dotfiles, submodules and nix packages that were completely uncoupled from the apps that
+ideal. I had to manage a mess of dotfiles, submodules and nix packages that were
-used them. Hyprland just assumed that I had all of my apps installed, assumed that otter-launcher's
+completely uncoupled from the apps that used them. Hyprland just assumed that I had all of
-config existed. Just by forgetting an app or a toml file, I had the potential to brick my entire setup.
+my apps installed, assumed that otter-launcher's config existed. Just by forgetting an app
+or a toml file, I had the potential to brick my entire setup.
 
 This is no longer the case.
 
-The solution is similar to that of safely typed languages, like rust. Rust, instead of having optional parameters
+The solution is similar to that of safely typed languages, like rust. Rust, instead of
-like typescript, requires that a variable be passed to a function, regardless of whether it contains anything.
+having optional parameters like typescript, requires that a variable be passed to a
-This leads to what is essentially a fixed dependancy tree, where there are no points of failiure, only allowing
+function, regardless of whether it contains anything. This leads to what is essentially a
-for logic errors and such. The same methodology can be applied to nix, using flake parts and wrapper scripts.
+fixed dependancy tree, where there are no points of failiure, only allowing for logic
+errors and such. The same methodology can be applied to nix, using flake parts and wrapper
+scripts.
 
-Instead of defining the packages beside the app, and its config, you can use the config to define the required binaries.
+Instead of defining the packages beside the app, and its config, you can use the config to
-By wrapping a config that contains a nix variable, ie a binary, that binary is intrinsically linked to that config,
+define the required binaries. By wrapping a config that contains a nix variable, ie a
-and will therefore always be installed. No more dependancy issues, and because the configs are defined within nix too, no
+binary, that binary is intrinsically linked to that config, and will therefore always be
-more potential for missing config files. Dotfile managers are no more, long live dotfile managers. Any app with a `--config`
+installed. No more dependancy issues, and because the configs are defined within nix too,
-flag can now be fully versioned and self contained within one repo, config and all, accessible on any machine with nix.
+no more potential for missing config files. Dotfile managers are no more, long live
+dotfile managers. Any app with a `--config` flag can now be fully versioned and self
+contained within one repo, config and all, accessible on any machine with nix.
 
-One command for a truly reproducible, fully contained, configured system. This is the endgame.
+One command for a truly reproducible, fully contained, configured system. This is the
+endgame.
+
+### Mandatory thing on AI
+
+I am not completely against AI. However, asking an agent to write a load of code and then
+posting it to reddit as if you made it yourself is disingenuous and (in my opinion) at
+least slightly morally incorrect. Many a time I have seen a cool project on a subreddit
+just for it to turn out to be ai generated garbage that I refuse to use out of principle.
+
+I would go out on a limb and say that 99% of this codebase was written with no AI
+assistance. Every config, every module, every obscure fix for a bug that only exists
+because I'm using a dendritic pattern instead of being normal was programmed by hand by a
+real human (yours truly). I'm not saying I had no assistance at all, there are sections
+that are verbatim copied from the wiki of whatever app or language that I was using, but
+by and large, no AI code has made it into this repo.
+
+There may be commits somewhere saying that opencode refactored something, or that it
+solved some obscure bug I was having, but after having those changes implemented for me, I
+took it upon myself to understand what actually happened, in order to make maintaining
+this config as easy as possible in the future.
+
+This repo is not temporary. I daily drive this, and I intend to for many years to come.
+Going forward, I will keep to the same standard of only using AI as a last resort, and
+when needs must, only implementing and commiting changes that I fully understand and
+could've eventually come to myself. Sometimes, at the end of a long coding session, a man
+gets lazy. I could spend another 45 minutes fixing some quickshell update order bug, or I
+could get deepseek to do it. In the end, it was a 5 line fix that, in hindsight, was
+pretty obvious (lol).
 
 ## Usage
 
-Usage is similar to any other flake, with everything in the module directory being an output.
+Usage is similar to any other flake, with everything in the module directory being an
+output.
 
 The folder structure is simply defined:
+
 ```
 modules/
 |- features/ - all available apps, every subfolder contains a seperate wrapped binary
@@ -43,12 +80,21 @@ modules/
 
 ### Nixos Configurations
 
-Due to the host module referencing `/etc/nixos/hardware-configuration.nix`, so that it is seperated from the repo,
+Due to the host module referencing `/etc/nixos/hardware-configuration.nix`, so that it is
-all rebuild commands will need `--impure`, unless you copy your configuration into the repo.
+seperated from the repo, all rebuild commands will need `--impure`, unless you copy your
+configuration into the repo.
 
-HACKSTATION is the heavier system, mobile02 is minimal and has no specialist hyprland config.
+HACKSTATION contains all features available (near enough), with mobile02 being a lighter
+version of the system, looking the same visually, but with less bloat, only really having
+firefox and a terminal.
+
+It is recommended to clone the repo beforehand, but the system can be built directly from
+remote. When cloning the repo, in order to properly evaluate the `vinix` and `nrs` shell
+aliases, the config should be built from the directory you cloned it to, not from another
+directory. When building from remote, or in any other scenario in which the `$PWD`
+environment variable is not available, the zsh module will throw and evaluation warning,
+but the build will not be hindered.
 
-It is recommended to clone the repo beforehand, but the system can be built directly from remote
 ```bash
 # Local Clone, . is the directory containing flake.nix
 sudo nixos-rebuild switch --impure --flake .
@@ -56,19 +102,37 @@ sudo nixos-rebuild switch --impure --flake .
 # Build from remote
 sudo nixos-rebuild switch --impure --flake "git+https://git.voidarc.co.uk/voidarc/nixos.git?ref=dendritic"
 ```
-Both of these commands can be appended with a desired hostname in order to build that configuration.
+
+Both of these commands can be appended with a desired hostname in order to build that
+configuration.
+
 ```bash
 # Example of building mobile02 from a local repo
 sudo nixos-rebuild switch --impure --flake .#mobile02
 ```
-There is no default output, so if the current hostname doesn't match a host, you will get an error.
+
-Building this config should be non destructive to any existing dotfiles, but will remove all users (not home directories)
+There is no default output, so if the current hostname doesn't match a host, you will get
-from the system other than `user01`, who's default password is `qwer`.
+an error. Building this config should be non destructive to any existing dotfiles, but
+will remove all users (not home directories) from the system other than `user01`, who's
+default password is `qwer`. No, that isn't my usual password.
 
 ### Binaries
 
 Any binary can be run with the same base command (will change when merged to main)
+
 ```bash
 nix run "git+https://git.voidarc.co.uk/voidarc/nixos.git?ref=dendritic#appname"
 ```
-`Appname` can be substituted for the name of any folder in the `modules/features` dir, ie `kitty` or `otter-launcher`
+
+`appname` can be substituted for the name of any folder in the `modules/features` dir, ie
+`kitty` or `otter-launcher`. Most if not all modules in a subdirectory will have a module
+name corresponding to that directory. This only applies for `default.nix` files, so files
+that have different names are not expected to follow this convention, even if there is not
+ea `default.nix` in that directory.
+
+## Issues and contributing
+
+Because this is a private git server, there is no inline way to submit issues,
+contributions, or feature ideas. If you should wish, you may send such requests to
+<admin@voidarc.co.uk>, with the format found in CONTRIBUTING.md. Failure to follow the
+format found there will most likely result in your email being ignored.

configs/common.nix

@@ -1,337 +0,0 @@
-{
-  config,
-  lib,
-  pkgs,
-  inputs,
-  ...
-}: {
-  imports = [
-    /etc/nixos/hardware-configuration.nix
-  ];
-
-  # Nix settings
-  ## Limit Cores on rebuild and enable Flakes
-  nix = {
-    registry = {
-      voidarc = {
-        from = {
-          id = "voidarc";
-          type = "indirect";
-        };
-        to = {
-          type = "git";
-          url = "https://git.voidarc.co.uk/voidarc/flakes.git";
-        };
-      };
-    };
-    settings = {
-      cores = 6;
-      download-buffer-size = 524288000;
-      experimental-features = [
-        "nix-command"
-        "flakes"
-      ];
-    };
-  };
-
-  ## Allow unfree packages and add pkgs.unstable
-  nixpkgs = {
-    config = {
-      allowUnfree = true;
-      packageOverrides = pkgs: {
-        unstable = import inputs.nixpkgs-unstable {
-          config = {
-            allowUnfree = true;
-          };
-        };
-      };
-    };
-  };
-
-  # Set <nixpkgs> correctly
-  nix.nixPath = ["nixpkgs=${inputs.nixpkgs}"];
-
-  ## Optimise Nix store on rebuild and collect garbage as a service
-  nix.optimise.automatic = true;
-  nix.gc = {
-    automatic = true;
-    dates = "daily";
-    options = "--delete-older-than 5d";
-  };
-
-  # Bootloader theming and plymouth
-  boot = {
-    loader = {
-      timeout = 2;
-      efi = {
-        canTouchEfiVariables = true;
-      };
-      grub = {
-        efiSupport = true;
-        device = "nodev";
-        theme = pkgs.catppuccin-grub;
-      };
-    };
-    plymouth = {
-      enable = true;
-      theme = "catppuccin-mocha";
-      themePackages = with pkgs; [
-        # By default we would install all themes
-        (catppuccin-plymouth.override {
-          variant = "mocha";
-        })
-      ];
-    };
-  };
-
-  ## Use latest kernel
-  boot.kernelPackages = pkgs.linuxPackages_latest;
-
-  # Bluetooth and Networking
-  hardware.bluetooth.enable = true;
-  hardware.xpadneo.enable = true;
-
-  networking.networkmanager.enable = true;
-  networking.networkmanager.dns = "none";
-  networking.nameservers = [
-    "1.1.1.1"
-    "8.8.8.8"
-  ];
-
-  # Locale
-  time.timeZone = "Europe/London";
-  i18n.defaultLocale = "en_GB.UTF-8";
-  i18n.extraLocaleSettings = {
-    LC_ADDRESS = "en_GB.UTF-8";
-    LC_IDENTIFICATION = "en_GB.UTF-8";
-    LC_MEASUREMENT = "en_GB.UTF-8";
-    LC_MONETARY = "en_GB.UTF-8";
-    LC_NAME = "en_GB.UTF-8";
-    LC_NUMERIC = "en_GB.UTF-8";
-    LC_PAPER = "en_GB.UTF-8";
-    LC_TELEPHONE = "en_GB.UTF-8";
-    LC_TIME = "en_GB.UTF-8";
-  };
-
-  # Userspace Stuff
-  ## Keymap
-  services.xserver.xkb = {
-    layout = "gb";
-    variant = "";
-  };
-  console.keyMap = "uk";
-
-  ## Desktop
-  services.xserver.enable = true;
-  programs.hyprland = {
-    enable = true;
-    package = inputs.hyprland.packages.${pkgs.stdenv.hostPlatform.system}.default;
-  };
-  security.polkit.enable = true;
-
-  ## Audio Server
-  services.pulseaudio.enable = false;
-  security.rtkit.enable = true;
-  services.pipewire = {
-    enable = true;
-    alsa.enable = true;
-    alsa.support32Bit = true;
-    pulse.enable = true;
-    jack.enable = true;
-  };
-
-  # Local User
-  ## User config
-  users.users.user01 = {
-    isNormalUser = true;
-    shell = pkgs.zsh;
-    description = "user01";
-    extraGroups = [
-      "input"
-      "root"
-      "plugdev"
-      "bluetooth"
-      "networkmanager"
-      "docker"
-      "wheel"
-    ];
-    packages = with pkgs; let
-      input = {
-        package,
-        output ? "default",
-      }:
-        inputs.${package}.packages.${pkgs.stdenv.hostPlatform.system}.${output};
-      wrap = {
-        name,
-        pkg,
-        modules,
-      }:
-        pkgs.symlinkJoin {
-          inherit name;
-          paths = [pkg];
-          nativeBuildInputs = [pkgs.makeWrapper];
-          postBuild = ''
-            wrapProgram $out/bin/${name} \
-              --prefix PATH : ${pkgs.lib.makeBinPath modules}
-          '';
-        };
-    in [
-      # Ricing
-      ## Desktop
-      bibata-cursors
-      catppuccin-gtk
-      unstable.waybar
-      hyprlock
-      dunst
-      wlogout
-      wpaperd
-      quickshell
-
-      ## Desktop Utilities
-      grimblast
-      gsettings-desktop-schemas
-      wl-clipboard
-      (wrap {
-        name = "otter-launcher";
-        pkg = (
-          input {
-            package = "otter-launcher";
-          }
-        );
-        modules = [
-          chafa
-          jq
-        ];
-      })
-      (input {package = "fsel";})
-
-      # Terminal
-      ## Styling / Functionality
-      oh-my-posh
-      carapace
-      zsh-autocomplete
-      bat
-
-      ## Tools
-      lazygit
-      git-secret
-      p7zip-rar
-      any-nix-shell
-      bluetui
-      fzf
-      ripgrep
-      wget
-      htop
-      playerctl
-      git
-      lsd
-      (input {
-        package = "doot";
-      })
-
-      ## Other CLI Apps
-      nodejs
-      fastfetch
-      opencode
-      tailscale
-      syncthing
-      jellyfin-tui
-      devenv
-      nix-output-monitor
-
-      # Apps
-      ## Actual Useful Stuff
-      nemo
-      kitty
-      firefox
-      gotify-desktop
-      pavucontrol
-      mpv
-      input-remapper
-
-      ## Other Nonsense
-      tor-browser
-      techmino
-      prismlauncher
-      delfin
-    ];
-  };
-
-  ## Zsh
-  programs.zsh = {
-    enable = true;
-    enableCompletion = true;
-    enableBashCompletion = true;
-    autosuggestions.enable = true;
-    syntaxHighlighting.enable = true;
-    histSize = 10000;
-    ohMyZsh = {
-      enable = true;
-      plugins = [
-        "git"
-        "dirhistory"
-        "history"
-      ];
-    };
-  };
-  users.defaultUserShell = pkgs.zsh;
-
-  ## User programs
-  programs = {
-    dconf.enable = true;
-    xfconf.enable = true;
-    gdk-pixbuf.modulePackages = [pkgs.librsvg]; # For wlogout svgs
-  };
-
-  ## User Services
-  services = {
-    gvfs.enable = true;
-    input-remapper.enable = true;
-    tailscale.enable = true;
-    printing.enable = true;
-    upower.enable = true;
-    openssh.enable = true;
-    avahi.enable = true;
-  };
-
-  ## Fonts
-  fonts.packages = with pkgs; [
-    nerd-fonts.fira-mono
-  ];
-  fonts.fontconfig.defaultFonts.serif = ["Fira Mono Nerd Font"];
-
-  # System Packages
-  environment.systemPackages = with pkgs; [
-    # Utilities
-    inputs.nvim-wrapped.packages.${stdenv.hostPlatform.system}.default
-    vim
-    unzip
-    python315
-    usbutils
-    curlWithGnuTls
-
-    # System
-    mesa
-    pkg-config
-    vulkan-tools
-    gvfs
-    wayvnc
-    clang
-    xdg-desktop-portal
-    xdg-desktop-portal-hyprland
-    glib
-    gnutls
-    liblzf
-    librsvg
-    appimage-run
-    libnotify
-    gsettings-desktop-schemas
-  ];
-  programs.gnupg.agent = {
-    enable = true;
-    pinentryPackage = pkgs.pinentry-all;
-  };
-
-  # The comment
-  system.stateVersion = "25.05"; # Did you read the comment?
-}

modules/attrs/music/default.nix

@@ -0,0 +1,11 @@
+{moduleWithSystem, ...}: {
+  flake.nixosModules.music = moduleWithSystem ({pkgs, unfreePkgs, ...}: {
+    environment.systemPackages = with pkgs; [
+      ardour
+      unfreePkgs.vital
+			distrho-ports
+      cardinal
+      calf
+    ];
+  });
+}

modules/hosts/mobile02/default.nix

@@ -10,6 +10,7 @@
       intelDrivers
 			development
 			upower
+			music
     ];
   };
 }

modules/system/audio/default.nix

@@ -12,6 +12,8 @@
       playerctl
       pavucontrol
 			pulseaudioFull
+			pipewire
+			pipewire.jack
     ];
     services.pulseaudio.enable = false;
     security.rtkit.enable = true;
@@ -24,6 +26,7 @@
       alsa.support32Bit = true;
       pulse.enable = true;
       jack.enable = true;
+			wireplumber.enable = true;
     };
   };
 }