Linux Automatic Installer (ansible) thread

Hi all,
@yaxu has kindly split this into it's own topic, so I'll give a proper blurb/introduction/explanation here:

What is it?
In short, it's a super simple way to get tidalcycles up and running with a variety of text editors.
It can also be re-run to handle upgrades as well!

Here is a (very rough) video demo:

What will it work on?
Modern debian based distributions. Currently Tidal requires cabal >=, so this is the first check to see if it's supported.

How do I run it?
You need ansible and git installed:

sudo apt-get install ansible git

Then you need to get the repository onto your local machine:

git clone --recurse-submodules
cd ansible-tidalcycles/

Then it should be as simple as:

sudo ansible-playbook --connection=local -i localhost,

Which will give you the course recommended tidalcycles + atom setup, configured startup.scd for supercollider, superdirt installed, samples fetched etc

Open supercollider, open atom, get livecoding!

But... atom isn't my favourite editor :frowning:
There are a variety of playbooks for other editors, and a vanilla playbook that just installs tidalcycles without any editor. Check them out here *.play.yml - I personally tend to use vscode and vim, so they've had a little more attention to their environment setup.
@yaxu, I'll probably add emacs at some point too :wink:

More questions you may ask:

I'm familiar with ansible, can I help?
Yes please! I'm documenting todo wishlist items in the, and problems via github issues. Please feel free to take a look at any of them, and submit a pull request.

I'm running a workshop and need to setup 20 machines...?
Yes - you could use ansible to "push" this configuration onto your 20 workshop machines


Hi I'm not familiar with ansible, but looks great, perhaps it could help with macos too?

I'm also looking into nix as a possibility for more reliable installation of haskell, tidal, supercollider and editors on linux and mac.


This is super interesting @cleary! Anything that can help with tidal installs would be so amazing. It's such a hassle at the moment and so many people don't manage to get it to work at all. As you might have noticed I spend a lot of time helping people debug installs..

@cleary - second @yaxu 's comment. While I'm happy with my 19.10 install now, I can't say that it was easy. This will be super useful for others.

1 Like

Hey thanks for the vote of confidence!
If you have time/interest would you mind doing me a favour and set up a second user account on your machine, login and run according to my instructions, then run supercollider/editor and confirm everything is communicating/working as expected?

I'll play devil's advocate if you don't mind..

There's a script here which works for mac os, or at least seems to work for some people :slight_smile:

I updated that repo version to also work for linux mint and probably other ubuntu/debian derived distros.

I'm now in the process of updating it to use nix to install tidal and supercollider, which I hope will get around most of the problems with cabal and sc, as well as work on a wider range of linux installs. I'm also making it check its own work rather than assume all its commands run correctly..

The question is, what are the pros/cons of ansible vs this? One 'con' is that ansible itself needs to be installed, and I think requires a working python installation.

We get a lot of trouble with installation because e.g. cabal assumes knowledge about computer science and software engineering, and not electronic music production :wink: Does ansible assume devops knowledge?

Sorry haven't had time to try ansible myself so these are naive questions.. I'm just trying to get a hold on whether we should improve tidal-bootstrap, or shift effort towards making ansible the default install method. I'd like to crack a genuinely easy tidal install method more than anything!

Excellent, thanks for working on this @cleary! I'd like to give this a try on a few machines. I do worry a little bit about Ansible requiring a lot of technical know-how to newcomers (e.g. folks who have never used a terminal), but a technical-yet-reliable approach would be better than a technical-and-troublesome approach.

I think any experimentation on this front is worth trying. Eager to give this a try soon.


Of course! I wouldn't expect otherwise :wink:

Yes, ansible must be installed on at least the executing machine - it is agentless (requires python) if you are pushing it out to other machines.

I think for most users we can expect that it will be executed locally on a single machine in 98% of cases though, so ansible must be installed.

I did a bit of reading because this question has to have been asked many times before.
This quote from Reddit seemed to put it most succinctly, but assumes programming knowledge:

...BASH is imperative; Ansible is declarative.

In bash you tell your script each little thing that you need to do, you have to write your system information gathering functions, build your error handlers, parse your files etc etc.

In ansible, system information gathering is already included as part of the connection process and immediately available to you in variables eg you'll notice that I use the variable "{{ansible_env.SUDO_USER}}" to make sure I'm executing as the user not as root on occasion. There's no work to discover this
Similarly I can get all operating system parameters, distro, major/minor versions etc.

The value in Ansible is that system interaction is generally done through quite bulletproof "modules" - an interface built for interacting with a component or area of your system with ansible. For debian packages, there is the apt module - I say what state a certain package or list of packages should be in on the system (installed/absent/latest/specific version etc), and that is all covered in a succinct and easily read stanza - eg

- name: install supercollider packages
    state: present
    update_cache: yes
    install_recommends: no
    name: [ 'supercollider',
            'zlib1g-dev' ]

But you could just write sudo apt-get install supercollider...etc? Yes - but this stanza handles being re-run and monitors state (idempotency) - if these things are already installed, the step is skipped and I'm notified in the output. The idea is that you aim to run the playbook against a system any number of times and always wind up with the same state.

Similarly for templating files, startup.scd for example - I use the template module to push the file out, take a backup, and have a jinja stanza in my template definition to insert 0 or more samples folders if they're provided in the playbook chosen.

Does ansible assume devops knowledge? Not for a user - they can just run the command. If you are going to develop it, then you need at least some sysadmin knowledge and ansible will tend to encourage you down a devops path by design.

If you are not using the ansible modules, and have to resort to a significant number of shell commands then ansible loses some of it's value. I've had to do this with the cabal handling, and the superdirt installation in sclang - but for the rest of the tasks, ansible is doing a lot of the heavy lifting you've had to do manually in your script.
It's easily read, self-documenting, modular (I've built it so that if someone wants to take my small sections (roles) and include them in their own ansible setup they want) and well supported.

As a side note, I live in bash scripts most of my day (I maintain a custom in-house linux distro as part of my role at work), but even my head is starting to explode at the branching conditions I'd have to be considering when I look at what you're attempting with your bootstrap script.
In ansible, I'd just make modular os specific roles (and potentially os version specific tasks), based on conditionals pulled from the information gathering process ansible builds in - in my head, this moves from exploding, to mild irritation :wink:

Here's a tiny subset as an example of what the information gathering looks like - all of this can be referenced by variables in the tasks/playbooks:

    "ansible_distribution": "Ubuntu",
    "ansible_distribution_file_parsed": true,
    "ansible_distribution_file_path": "/etc/os-release",
    "ansible_distribution_file_variety": "Debian",
    "ansible_distribution_major_version": "20",
    "ansible_distribution_release": "focal",
    "ansible_distribution_version": "20.04",

The entire set of info it pulls on a random laptop I've setup is here:

Can it work on mac? Yes - I have no experience with it though - here's a relatively modern article:

Can it run on windows? Yes - I have some exposure through a shared SOE role I use at work for keeping our SOE in sync (eg browser versions across platforms). I believe it's far fiddlier to setup though, and far less complete than either of the above os'

So I don't know if this answers your question, I've got the benefit of a few years ansible experience under my belt (and my early experiments weren't very good), so I have a bias. But I do have a lot of experience bash scripting as well, so I can at least compare the two with some similar level of detailed knowledge.

1 Like

Cool, I was always interested in learning ansible, would give it a try for sure.

I'll give this a try this weekend and report back.

1 Like

@cleary I set up a new 'tester' user on my ubuntu studio 19.10 install and almost made it but got the following errors: gist

Note that for the tester user, I did log out and back in, but did not restart.

Also, when I logged out and logged back in as my regular user, I got the same error about not being able to "initialize audio". I restarted and my normal user/tidal config did not produce the same error.

1 Like

ok, thanks for running. The atom repo keys error is an unexpected place to fail - I'll dig into that in my own time.
Regarding the audio, I'm heading out of my depth right now - personally I use jackd as my audio subsystem, if that's familiar to you from your previous user then make sure you've started the jack server (i use qjackctl for that).

If not, then you've reached the limits of my supercollider knowledge :wink:

Thanks for testing, if nothing else, you've highlighted that it needs a little more work, and significantly more testing - or that I will need to be very careful about how much time I commit to supporting different setups... :grimacing:

Thanks for all the info!
I'm still interested in nix though. In theory it's a one liner to install, another to safely install haskell, tidal, supercollider and an editor, a superdirt checkout, and that's more or less it.
Unfortunately the supercollider package doesn't seem to work outside of nixos, for reasons related to gl.. Bah!

All good Alex!

I was having a very brief look into the python interfaces for supercollider, which in theory mean I could build a proper ansible module for interfacing with SC... I'd like to follow that path, but the most promising looking project "SC" is 8 years old :frowning:

I'm interested in all this stuff, less to solve tidal problems and more to understand the nuts and bolts behind ansible/supercollider/CI testing so I'll probably notch away at it all as I have time and energy too :slight_smile:

1 Like

The Nix version of Atom isn't working for me either (crashes when I try to open/save a file), so I'm giving up on that path now..

Do you think your ansible method is ready to put on the Tidal install page for Linux @cleary?

@yaxu maybe, thinking through all the things I'd like to do with it, I think there's only one thing I need to do before you go ahead:

Currently I have custom synth paths as a variable defined in each individual playbook, which means you have to make sure that variable is present in all playbooks if you want to try different editors. I just need to make it global, it shouldn't take long - I'll have a look at it today/tonight tomorrow and ping you back when it's done.

I'd also like to look at being able to handling more interesting scd startup variables in there too (custom midi, additional synth defs etc) but getting the custom vars moved to a global scope is really the first thing to do, and the only thing blocking you adding it to the front page.

1 Like

@yaxu lol, so much for that optimism.

There was a 30 day time limit for editing posts. I've reconfigured it so now people should be able to edit their post forever. Thanks for all this btw!

1 Like

all done, I guess that's ready to release to the seething hordes of tidalcycles users :grimacing: :stuck_out_tongue:


Great! Do you have time to add instructions to the wiki, and then link it here as the 'easy' option?

Happy to close this issue: :slight_smile: