In these resources OS X 10.11.6 and 10.12.6 have been used to test commands.
Although OS X is a Unix based operating system, Apple does not give you all the typical Unix command line tools. You need to install them yourself.
First the command line tools from Xcode need to be installed. Open Terminal.app (or do yourself a favour and install the free iTerm2: https://iterm2.com) and run:
xcode-select --install
This gives you the compiler you need to build the next set of tools which come from Homebrew (https://brew.sh). To install these type (or paste) into a terminal:
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Finally you need to use the Homebrew package manager to install wget and cmake:
brew install wget cmakeYou now need a location for the VCVRack source code. This is up to you. For example, I created the directory /src/VCVRack/ under my home directory and will use it in the following examples.
mkdir ~/src
mkdir VCVRack
cd ~/src/VCVRack
pwd
In these resources Windows 10 has been used to test commands.
Windows needs a Unix-like environment to build Rack and its modules. To get this visit http://www.msys2.org and download and install the x86_64 variant of msys2.
After installing it a terminal window will open (if it does not choose msys2 from the Windows Start Menu). Type the following:
pacman -Syu
You will be invited to continue with installation:
:: Proceed with installation? [Y/n] y
if the installation suddenly stops with a message like:
warning: terminate MSYS2 without returning to shell and check for updates again
warning: for example close your terminal window instead of calling exitExit MSYS2 and then start it again from the Start Menu (always choose the 64 bit version: MSYS2 MinGW 64 bit) and complete the installation with:
pacman -Su
If something goes wrong then you will need to check the detailed install documentation: https://github.com/msys2/msys2/wiki/MSYS2-installation.
Having installed the basic Unix-like tools you now need to install packages for building software (compilers etc):
pacman -S mingw-w64-x86_64-gcc make mingw-w64-x86_64-cmake tar unzip gitYou now need a location for the VCVRack source code. This is up to you. For example, using the Windows File Explorer I created the directory C:\src\VCVRack\ and will use it in the following examples.
To change to the location where you will build Rack and/or run scripts you need to issue the following command in the MSYS terminal:
cd /c/src/VCVRack
In these resources Ubuntu 17.10 has been used to test commands.
Most Linux users should be familiar with both the command line and building applications from source.
To check you have the main required tools listed on the main GitHub Rack page, type gcc, make, cmake, tar, and unzip in a terminal to establish that everything needed is there.
If anything is missing you will need to use your distribution’s package manager to install it.
Depending on your Linux distribution you may well find that other things are missing when you attempt to build Rack. If the build fails you need to look at the output and find out what is missing, usually achievable by sticking the error message into a search engine. For example, Ubuntu 17.10 was missing quite a few libraries, installable with:
sudo apt install git cmake libx11-dev libgl1-mesa-dev libxrandr-dev libxcursor-dev libxinerama-dev zlib1g-dev libasound-dev g++ libglu1-mesa-dev libgtk2.0-devYour mileage will most certainly vary with other distributions and this is the current limit of Linux support in these pages for reasons outlined here: A note for Linux users. Good luck!
Rack, and its distribution modules (Fundamental, Audible Instruments, Befaco, E-Series), and many third party modules are 'open source'. Their code is typically installed on a server that provides 'git' services, a distributed version control system. Rack and almost every module released for it is currently stored on GitHub, though you may find modules stored on GitLab (already) and Bitbucket too (in the future).
To build Rack and modules you need nothing more than to know how to 'clone' a repository and how to retrieve submodules for that repository, which will be covered on the next page. You may, however, have cause to look at Rack or an individual modules's online repository for information so this is intended as the briefest of guides to potentially relevant sections of a GitHub repository. Other git service providers offer the same services though their online interface may vary slightly.
When you visit a repository's URL you are presented with a list of files and folders; these are the most current files. This is the 'Master' branch of the repository. (Sometimes there may be other branches, or there may be tags, which can be seen by clicking on the Branch button just above the 'Latest commit' message; in the case of the main Rack repository you will see that there are tags for the various releases.)
On the right hand side there is a 'Clone or download' button. This provides the URL of the repository itself (normally the same as the web address with '.git' appended). You can copy this URL by clicking on the clipboard icon next to it and then paste it into the command line when retrieving the files ('cloning the repository'). At the bottom of the page, below the list of files, you may find information about Rack or modules including anything special you need to know about compiling them.
Above these buttons on the left is a list of 'commits'. This is a list of previous revisions of the contents of the repository. If the current version of a module is not building or working properly you may wish to try an earlier version. With third party modules that lack version numbers you may have to do some detective work here to figure out which version is the latest one that will build for a given Rack version (though you also check the build commands in the Build Monitor here).
To the right of this there may be a link to 'releases'. These are important snapshots of the source code at a particular time, normally when it is stable, and may also contain binary (compiled) releases. Rack and its distribution modules are released with version numbers (0.4.0, 0.5.0 etc) and third party developers are encouraged to do likewise. The latter often add letters to successive releases (0.4.0a, 0.4.0b etc). Marrying up these numbers is an important clue in determining which version of the source code of a module is likely to build successfully for a given Rack version.
This is where problems are raised with Rack and modules, discussed and fixed. If you are having a problem it is worth checking both open and closed tickets.
More detailed documentation (if any).