Sender | Message | Time |
---|---|---|
28 Sep 2022 | ||
sjfloat Which browser are you using? | 14:48:47 | |
Chrome | 14:49:14 | |
> So, I'm consider going a completely different route. In particular, I think I'll try to get as much of the audio stuff out of the system config as possible. Why is that? For me, the main reason to start using NixOS, is so that I could have all my config (except dotfiles, so far) in a file. | 14:50:50 | |
Partially because I don't consider jack a system-level thing. I tend to manipulate things as part of what I'm trying to do. | 14:52:13 | |
I don't want my jack config that static | 14:52:32 | |
I agree that pipewire probably is the future. It just doesn't solve any problem that I have. | 14:53:42 | |
Do you mean you've been able to use the first config sufficiently for pro audio?
I took that as meaning you wanted it in your user config, e.g., with home-manager, but it seems you need it to be mutable? | 14:53:44 | |
Yeah, I don't even want it in home-manager | 14:54:24 | |
ctem yes | 14:54:29 | |
I might have a session definition that changes my jack config | 14:54:43 | |
@ctem I have mostly been making music though. If I was recording I would definitly boot into thr RT kernel! | 14:55:24 | |
Now it would be awesome if I can get the entirety of my project in a nix-shell or something. | 14:55:27 | |
Then the project would be more hermetic and not subject to how a particular system was configured at a particular time. | 14:56:37 | |
Stated another way, I'd like my music projects to be decoupled from the system. | 14:57:44 | |
magnetophon: Noted. Thanks!
I’m also considering treating audio productions like programming projects, e.g., with a Nix flake specifying any hosts, plugins, etc. It would be interesting to solve music collaboration the Nix way. | 14:58:31 | |
Yeah, that's my approach. I use git-annex to store audio files. | 14:59:22 | |
i.e. tracks from recording. | 14:59:44 | |
Same here. I haven’t published my configs yet but wrote this design document as a start to describe a NixOS/mesh VPN/git-annex way to collaborate. | 15:01:44 | |
Oh, nice! I started using annex (for audio files) at one point, but got a bit overwhelmed by it. Maybe I should look into it again! | 15:02:54 | |
At the time I started using it, git didn't support large files. Native git might be a better choice now -- I don't know for sure. | 15:03:56 | |
I’d hoped that by the time I got to writing that document that everything would be solved by IPFS, but for now I think git-annex is still best-in-class. | 15:04:01 | |
It has a borg remote that’s great for use with, for example, an SBC w/a big backup drive attached to it (presumably stuck in the corner of the room of as many collaborators as possible). | 15:06:22 | |
Why annex on top of borg instead of just annex? For the encryption? | 15:07:26 | |
Yes, for a collaborative setup, encryption is part of it. Compression and dedup are also a big help. | 15:08:38 | |
How well does the compression and dedup work for audio? | 15:09:26 | |
I haven’t used this setup long enough to provide any numbers, but for example, if multiple collaborators are creating borg archives of the same project and many of the same files, borg's dedup should really shine. With git-annex alone, a git-annex cache might be helpful but wouldn’t provide any of the features you get w/borg for free. This is still an experiment, but the idea is to use borg to back up git-annex repos onto backup drives and keep git-annex working trees on workstations. Another thing I should mention is that while I devised this w/music collaboration in mind, it’s implemented to be all-encompassing. (So in this case, borg will end up compressing and deduping a lot more than just audio.) | 15:19:26 | |
Sounds good, thanks! | 15:20:14 | |
@ctem If you end up publisching the NixOS config you use for that, let me know! | 15:20:49 | |
I certainly will! Just need to lock in a few more things...and document it a bit further! (It’s also set up using my roll-your-own provisioning tool to help w/the process, so I think ample documentation will be crucial.) | 15:24:12 |