Compare commits
No commits in common. "5195a358287cf916f3d46612cb266a0a3d36ee85" and "51d13c003f6047420c4c3539e6b74d65a05886d8" have entirely different histories.
5195a35828
...
51d13c003f
@ -43,7 +43,6 @@ GPG is also often used to encrypt email and other forms of communication in open
|
||||
|
||||
GPG keys are very similar to SSH keys, but notably different in that they force the use of a password, while SSH keys may be passwordless.
|
||||
They also differ in that GPG keys aren't named, but rather are stored on a keyring.
|
||||
I will leave it for a future post or to someone else entirely to explain what a keyring is.
|
||||
|
||||
I first installed [gnupg](https://gnupg.org/) and created a GPG key using `gpg --full-gen-key`.
|
||||
I gave it my email address, set it to expire after a year and used otherwise default encrpytion options.
|
||||
|
||||
@ -1,91 +0,0 @@
|
||||
# Wading into Tidal
|
||||
|
||||
I stumbled across [TidalCycles](https://tidalcycles.org/) lately.
|
||||
It exists at my happy cross-section of automation, rave music and open source software.
|
||||
It's a [livecoding]() language/interpreter/instrument based on Haskell (in which I am also particularly interested!) and I decided to try it out.
|
||||
|
||||
This is a short post explaining the steps I took and resources I used to install and get started playing with Tidal on Arch Linux using Neovim.
|
||||
|
||||
# Realtime Scheduling
|
||||
|
||||
Similarly to a DAW - I suppose Tidal is kind of a DAW? Audio engineers will squirm - it's important for Tidal to have high-precision timing, unlike most software.
|
||||
This kind of control can be risky, so most systems don't make it available straight out the gate - Arch is one of them.
|
||||
See [this post](https://jackaudio.org/faq/linux_rt_config.html) for a more detailed explanation, as well as a list of distributions which do enable realtime scheduling straight away.
|
||||
In my case, I found a section on the [JACK ArchWiki page](https://wiki.archlinux.org/title/JACK_Audio_Connection_Kit#Realtime_scheduling_and_additional_resources) that provided an easier solution.
|
||||
Install the `realtime-privileges` package and add your user to it:
|
||||
|
||||
```
|
||||
sudo pacman -S realtime-privileges
|
||||
sudo usermod -a -G realtime ktyl
|
||||
```
|
||||
|
||||
As with all group changes, you'll need to re-log or reboot for changes to take effect.
|
||||
|
||||
# Linux Audio
|
||||
|
||||
There are three components to my local audio setup in the context of Tidal.
|
||||
First is [JACK](https://wiki.archlinux.org/title/JACK_Audio_Connection_Kit#Realtime_scheduling_and_additional_resources), which is a low-latency audio daemon with a confusing number of implementations.
|
||||
There is a list and comparison on the ArchWiki page, but I found the package I needed to install was `pipewire-jack` (as opposed to `jack` or `jack2`), which leads nicely into Pipewire, the second component.
|
||||
|
||||
[Pipewire](https://wiki.archlinux.org/title/Pipewire) is a multimedia framework which aims to solve audio problems on Linux Once And For All.
|
||||
It's an abstraction and doesn't directly play audio itself, rather deferring that responsibility further down the line.
|
||||
|
||||
To actually play audio, I am using the [PulseAudio](https://wiki.archlinux.org/title/PulseAudio) which I already had installed.
|
||||
However, this didn't work out of the box because Pulse and Pipewire had no idea about each other.
|
||||
To resolve this, I had to install the `pipewire-pulse` package.
|
||||
|
||||
# SuperCollider and SuperDirt
|
||||
|
||||
Now we're getting to the fun stuff!
|
||||
I mostly followed [this guide](https://roosnaflak.com/tech-and-research/install-tidal-cycles-on-arch-linux/), but I found I had to do a couple things a little differently - maybe it's a bit of a dated guide? - which I'll describe here.
|
||||
|
||||
First I installed `haskell-tidal` from the AUR (I use the [`yay` AUR helper](https://github.com/Jguer/yay).
|
||||
Then, as I wanted to use Neovim, I had to install the `tidalcycles/vim-tidal` plugin, using the [`vim-plug` plugin manager](https://github.com/junegunn/vim-plug), and remembering to run `:PlugUpdate`.
|
||||
|
||||
The guide then describes steps to make the `tidal` binary available system-wide - however I found the path it describes didn't exist.
|
||||
Instead, based on the path `vim-plug` installs to (`~/.local/share/nvim/` rather than `~/.config/nvim/`), I found my actual steps were:
|
||||
|
||||
```
|
||||
cd ~/.local/share/nvim/plugged/vim-tidal
|
||||
sudo make install
|
||||
```
|
||||
|
||||
Next I opened SuperCollider with `scide` and installed SuperDirt.
|
||||
Again the guide seemed a bit out of date in the version of SuperDirt it lists - I found I needed to use `"v1.7.2"` as the version string, rather than `"v1.1.3"` as shown in the guide.
|
||||
By the time you're reading this, the version listed here may be out of date, so if you have trouble with this stage that's what I'd check first.
|
||||
|
||||
```
|
||||
Quarks.checkForUpdates({Quarks.install("SuperDirt", "v1.7.2");
|
||||
thisProcess.recompile()})
|
||||
```
|
||||
|
||||
To run code in SuperCollider, select the block you'd like to execute and press `Ctrl + Enter`.
|
||||
|
||||
At this stage, everything should be installed (notwithstanding any error messages, troubleshooting section not included) and we should be ready to go.
|
||||
|
||||
Start SuperDirt up in SuperCollider:
|
||||
|
||||
```
|
||||
SuperDirt.start;
|
||||
```
|
||||
|
||||
Now, open a tidal file in Neovim:
|
||||
|
||||
```
|
||||
nvim test.tidal
|
||||
```
|
||||
|
||||
And enter a Tidal pattern!
|
||||
|
||||
```
|
||||
d1 $ sound "bd sn"
|
||||
```
|
||||
|
||||
To play it, put the cursor in the line and press `Ctrl + E`.
|
||||
Neovim should open a new window containing a Tidal terminal, and find and connect to the runing Tidal instance.
|
||||
|
||||
That's it!
|
||||
Have fun making beats.
|
||||
If you have any trouble with this guide, there's an off chance I've learned a bit more about in the interim, so feel free to [ping me an email](mailto:me@ktyl.dev)!
|
||||
Or of course, ask the nice folk over at [Tidal Club](https://club.tidalcycles.org/).
|
||||
|
||||
71
drone-ci.md
71
drone-ci.md
@ -1,71 +0,0 @@
|
||||
# Drone CI
|
||||
|
||||
When it comes to automation, [GitLab CI](https://gitlab.com) has been my go-to for running builds, tests and deployments of projects from static websites to 3D open-world games.
|
||||
This has generally been on a self-hosted installation, and often makes use of physical runners.
|
||||
However, I have some gripes: I mostly only use it for the CI, but it comes with an issue tracker and Git hosting solution too - great for some cases, but overkill in so many others.
|
||||
Because it's such a complete solution, GitLab is a bit of a resource hog, and can often run frustratingly slowly.
|
||||
|
||||
Recently I've been playing with a friend's self-hosted instance of [Drone CI](https://drone.io/) as a lightweight alternative, and I much prefer it.
|
||||
I didn't set up the instance, so that part is out of scope for this post, but in case it's relevant, we're using a self-hosted [Gitea](gitea.io) instance to host the source.
|
||||
You can find out about configuring Drone with Gitea [here](https://docs.drone.io/server/provider/gitea/).
|
||||
|
||||
|
||||
## Yet Another Yaml Config
|
||||
|
||||
Like GitLab, Drone is configured via a YAML file at the project root, called `.drone.yml`.
|
||||
Drone is configured by creating 'steps' to the pipeline, where GitLab uses 'jobs'.
|
||||
|
||||
My first project's automation requirements were small - all I needed for a deployment was to copy all the files in a directory on every push to the `main` branch.
|
||||
This means I needed secure access to the host, and the ability to copy files to it.
|
||||
I didn't want to dedicate any permanent resources to such a small project, so opted for the `docker` pipeline option.
|
||||
|
||||
My pipeline would contain a single `deploy` step which would configure SSH access to the host, and then use it to copy the relevant files from the checked out version of the project.
|
||||
I decided to use `ubuntu` as the Docker image for familiarity and accessibility - there are probably better options.
|
||||
Drone widely supports Docker image registries; I have not used Docker much, but would like to get more experience with it.
|
||||
|
||||
```yml
|
||||
kind: pipeline
|
||||
type: docker
|
||||
name: deploy
|
||||
|
||||
steps:
|
||||
- name: deploy
|
||||
image: ubuntu
|
||||
when:
|
||||
branch:
|
||||
- main
|
||||
|
||||
commands:
|
||||
- echo hello world
|
||||
```
|
||||
|
||||
## Secrets
|
||||
|
||||
A hugely important aspect of automation is ensuring the security of one's pipelines.
|
||||
Automated access between pipelines is a big risk, and should be locked down as much as possible.
|
||||
For passing around secrets such as passwords and SSH keys, Drone has a concept of secrets.
|
||||
I created a private key on my local machine for the runner's access to the remote host, and added a [per-repository secret](https://docs.drone.io/secret/repository/) to contain the value.
|
||||
This is a named string value which can be accessed from within the context of a single pipeline step.
|
||||
|
||||
I also created secrets to contain values for the remote host address and the user to login as.
|
||||
These are less of a security concern than the private SSH key, but we should obfuscate them anyway.
|
||||
It's also a useful step towards generalising the pipeline for other projects, which we'll get into later.
|
||||
|
||||
This block was placed in the same step definition as above, below the `image:` entry:
|
||||
|
||||
```
|
||||
environment:
|
||||
HOST:
|
||||
from_secret: host
|
||||
USER:
|
||||
from_secret: user
|
||||
SSH_KEY:
|
||||
from_secret: ssh_key
|
||||
```
|
||||
|
||||
## Templates
|
||||
|
||||
## References
|
||||
|
||||
* [GitLab CI config to deploy via SSH](https://medium.com/@hfally/a-gitlab-ci-config-to-deploy-to-your-server-via-ssh-43bf3cf93775)
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user