Building a multimedia system on any OS is a precarious task; you want to maximize the flexibility, you want to have every tool available to you with as much integration as possible. You want the latest features, you want to understand the tools of the trade, and you want a solid system that is stable, powerful, and will, as they say, eat any and all media for lunch.
There are quite a few distributions of Linux geared toward multimedia. These might be good to sample available multimedia applications available on Linux, but typically if you are an artist then you have specific requirements, specific tools and combinations of tools that you prefer, and probably a unique workflow. The best solution is to build a custom environment for yourself and your work.
Slackware has long been known for its stability and flexibility. People use Slackware for everything from pocket distros (Slax) to servers, desktop systems, and even as a basis for building their own distributions (Wolvix, Zenwalk, and many others).
Building and distributing a multimedia distribution based on Slackware would go against the very idea of creating a completely customized multimedia distribution; so this article will be a "Text Based Distribution"; that is, a tutorial on how to build your own multimedia system upon a base Slackware install. Like the Linux-From-Scratch (LFS) project, part of the distro is the process of you creating it, and part of the power of creating your own distro is the ability to change things to suit your needs. The distro you end up with may well be quite different than the system described in this article, but that is why there are no .iso's for straightXedge gnu+linux.
Install Slackware and configure it for your machine. If you've never installed Slackware before, this article may or may not be a bit advanced for you. You will need to know how to get a comfortable, working Slackware system installed and configured; good resources for this are practice (it makes perfect), Alan Hicks's slackbook project and Jeremy's Linux Questions forum.
This having been said, there are some hacks around having to install and configure Slackware the traditional way, such as downloading the cd iso for Zenwalk and installing it. This is a Slackware-based distribution which is essentially Slackware with a more GUI installer and configuration stage, and XFCE instead of KDE. There are no extra steps required to use traditional Slackware tools like slackpkg and sbopkg. Another such potential alternative is SLAMPP, which similarly does not use KDE by default but is fully compatible with all the usual Slackware tools and packages. While these may be easier for some to install, there may be less customization since you are relying on the distro to set up much of your environment, and building from source may or may not require additional steps such as obtaining kernel headers and development tools. Therefore, this hack around installing Slackware may require hacks around not having install Slackware, as it were; installing Slackware proper is encouraged.
Once your Slackware system is installed and configured, you should create a multimedia user. This is by no means a required step but some might find it a conveient way to create a dedicated environment for multimedia work. This user might have, for instance, a fluxbox or xfce desktop to maximize system resources available for heavy multimedia applications, and a home folder organized specifically for their projects (a series of Samples or Synth Bank directories, for instance, or a directory dedicated to stock footage, and so on).
To do this, simply invoke the adduser command and create your multimedia user. As that user, set your desktop environment with this command:
Set up slackpkg by editing /etc/slackpkg/mirrors and choosing one (and only one) mirror from either the Slackware version you are running, or from Slackware-current to stay up-to-date with new additions to Slackware. Setting it to the Slackware version you are running is very safe and is the same as having a Slackware .iso ever-present in your drive from which you may install official Slackware packages should you ever need to do so. Using Slackware-current is less safe because your repository is now mirroring the latest additions Pat Volkerding and the Slackware team are posting in preparation for the next version. However, running -current is common and as long as you upgrade infrequently and wisely, you will probably maintain the stability of your system.
SlackBuilds.org has been a well-known and important part of Slackware for years now, and sbopkg is Chess Griffen's frontend for it. Sbopkg acts and feels very much like BSD's "ports" system, and makes installation of unofficial Slack Packages as easy as a few keystrokes. You should download the latest sbopkg package and install it:
If you don't know already, learn to use sbopkg.
Many of the dependencies, libraries, and backend apps are already installed on a default Slackware install, and many others can be optained easily and quickly via sbopkg. The question is whether or not you should build a given dependency or application from source code yourself.
Building from source yourself gives you the ability to build the application so that it has the features that you need, whereas relying on a Slackbuild or a prepackaged binary may not give you the same control over what you are installing.
Armed with a little knowledge, gained from reading the README files in the code, or the slackbuild scripts from within sbopkg, it is safe to install most all libs and many dependencies from sbopkg or other sources, and other dependencies or major applications at your own discretion.
Mind the order in which you install libraries and dependencies; if you attempt to install, for instance, Inkscape before you install gc or libsigc++ then the install will fail, so sequence is important.
You know your required applications best, but here is a sample of a visual artist's potential list of installs in the order of installation:
This gives you a solid foundation for a wide variety of more discipline-specific applications. Feel free to customize this base install as you see fit; you may not need so many video codecs, or you may opt for a different id3 tag editor, and so on. However, installing the above layer of dependencies and libraries prepares your system quite well for more discipline-specific applications, which can be separated into "modules". There is no reason not to install all modules, but the modular approach allows you to ignore discplines you have no interest in (ie, if you are a visual artist and have no need for a robust audio workstation, or if you are exclusively a musician and have no need for video or graphic tools.)
A very robust Slackermedia install will involve over 50 packages from sbopkg and more to be built from source. The sbopkg queue file for all the packages listed on this site can be downloaded here and placed into /var/lib/sbopkg/queues/ and then loaded into sbopkg as a queue to process. Feel free to add to it or subtract from it as needed.
Because Linux does not have a staff of musicians packaging sets of samples, synth banks, drum loops, and so on, it is up to the artist to create and/or compile the components of their art work. This means that either you should spend time gather together whatever raw materials you will require for your art, whether by creating your content or gathering it from outsides sources like freesound.org or Computer Music Magazine.
As with the music module, you will need to gather together your raw materials since, luckily, Linux does not come pre-packaged with a standardized set of pre-fabricated artistic components. Typically helpful for the graphic artist is a good set of fonts, which you should collect and back up for re-installs; many good free fonts can be found at dafont.com -- but check the licensing policy of each font as all are not necessarily free for all kinds of usage. Stock photography also often helps; a good resource is flickr which allows searches within various Creative Commons licensing schemes.
ffmpeg is the backbone of many video-related applications from players to editors (and is in fact even both of these things in itself). For the most flexible system possible, ffmpeg should be intalled from source code. It's a big application with many of options and you will want to have control over whether these options are enabled or disabled. To learn about the options, read the ffmpeg compiling documentation found in the source code tarball, and then try ./configure --options
A sample configuration for a diverse system:
Blender is a powerful application that you can use for graphics or video editing -- or both -- as well as motion graphics, game programming, desktop publishing, and quite a lot more. It is also very actively developed, with new features arriving fairly often. While there are pre-compiled binaries available on the blender.org site (and through sbopkg) for 32-bit and 64-bit systems, the binaries force you to use their version of ffmpeg which may not be the best version of ffmpeg for your needs.
The compilation process of blender is not as complex as it might seem at first glance. On a default Slackware system, most of Blender's dependencies are already installed and there is no need for "development" versions of anything as there are on distributions like Fedora or Ubuntu.
If you installed all of the dependencies (primarily for Blender: scons, openAL, ftgl, smpeg, and gettext) listed as the starting point for this multimedia version of Slackware, then the process is simple:
Download the source code from their site. The development team offers you a stable release tarball as well as the development code from svn; you will want to go with the stable release. Untar the downloaded archive (tar -xzf blender-2.x.tar.gz), cd into blender-x.x/ and type scons. Yes, there is no ./configure && make && su -c 'make install' -- it's just "scons".
The binary itself will be located in a directory called build/linux2/bin/ and will be called, of course, blender. You may move this executable file to whatever location is most convenient for you; such as /usr/local/bin.
Unexpected errors are common enough to warrant a note about them. Blender is frequently developed, and building it from source will sometimes render a puzzling error. Chances are, of course, that someone before you has experienced the same error, so simply do an internet search on the error in order to find a solution or work-around. In 2.49b, for instance, there were issues with xvidcore, resulting in a nasm.inc error during compilation. An internet search would reveal a post in the Blender forum about the error, why it was happening, and the current workaround.
Errors do happen, but they needn't dissuade you from compiling important applications from source.
Transcode is similar to ffmpeg but has some unique features, and is also a recommended dependency on some other major applications. Like ffmpeg, it has many options that you will want to ensure are enabled and others that can safely be left disabled. While there is a slackbuild for it, I find it better to compile from source. A sample ./configure invokation:
HandBrakeCLI is a commandline DVD ripper that will read DVDs and convert the native muxed mpeg2 files to some other format, like Ogg Theora, x264, and others. It is one of the many invaluable tools for the video editor, who can typically expect to receive video from every imageinable source. The compilation is simple, but requires both yasm (an extra on the Slackware install disc) and jam (available via sbopkg). Similar to Blender, the build process results in a binary called HandBrakeCLI that should be moved to a more suitable location, like ~/bin or /usr/local/bin.
Digikam is a direct competitor to powerful digital darkroom applications as well as to photo managers. It is fully featured, powerful, and has a rich plugin structure which enables even more features. Even if a graphic artist or photographer is happy using GIMP or Krita, digikam is an important tool for its workflow and image manipulation ability. Compilation is fairly simple, although it uses cmake rather than the usual ./configure && make && make install sequence. Instead, you first have the options to export key variables such as the location of the qt libraries you wish to use, and then issue cmake with whatever options you feel are necessary, and then (as root) make install. Here is a sample:
LiVES is a Video Editing System. Once again, being built upon powerful free software like mplayer, mencoder, sox, and more, there are few formats it cannot support. It features a number of high quality realtime effects. The interface is unique but it is flexible enough to offer fairly conventional means of achieving results, as well. Compiling is self-explanitory.
more to come...