SLab 2.30 is the current stable version of a hard disk recording system for linux. It's GUI represents a reasonably standard mixing desk with faders for each channel and send and return busses for effects. Anyone who has had experience of real mixing desks will have little trouble finding their way around. SLab 3.0 (in alpha form) looks very much the same. The mixer has new tape buttons and there a few other small alterations. In the background are a whole bunch of new effects and substantial differences in the way samples are handled.
SLab is available here.
Here are some notes on the upcoming Slab 3.0 and beyond by Nick Copeland ...
Until 3.0, SLab only mixed with 32 bit integers. The filters were applied to 16 bit samples, and the bussing and final mixdown was done with 32 bits, which was basically a 16 bit sample with 8 bits of headroom and 8 bits of accumulation (tailroom?). This is fine, but for filtering and any major DSP work, using floats is far more acceptable since it can support almost infinate headroom with no loss of resolution. SLab 3.0 introduced a full floating point mix, including filters and in-line DSP (echo/reverb/chorus without needing to use the send busses). You have to request floating point mixing explicitly from the audio->algorithms menu, and the default is to use integer. Also included in the floating point mixing is the ability to re-order the mixing operations, so you can apply filtering before FX, or FX before filtering - build your own mixer, plus a few other features for real "dual mix" configurations.
Where is SLab going? When 3.0 is finalised I want to work on some audio driver improvements to give better synchronisation across multiple soundcards (3.10), and whilst this is going on I will buy a CD burner and finish off a cdrecord/cdwrite frontend.
Release 4.0 will be able to burn master CDs, not on its own, but by linking into somebody elses CD-W driver. These releases would have other features in as well - I will see what I need to do for a multitrack viewer. After that? Loads of things - MIDI synchronisation to allow SLab to play along with a MIDI recording system. I do not intend to write a MIDI recorder/mixer, other people have done this already and have done a pretty good job. I would like SLab to respond to MIDI controllers, so that you could use an external controller block to mix each track - hands on to knobs is better than mouse control. SMPTE sync would also be interesting, but there is rather limited soundcard support for SMPTE interface signalling. I would like to add an oscilloscope which can be tapped into the mixing algorithm at (almost) arbitrary points, help to track down distortion and control volume levels. The automated mixing requires an overhaul to improve is granularity. Fortunately this is backend stuff, since each controller already sends events to the session recorder, it is only the recorder that needs to be reworked.
On top of that I would like to build something like DrumSLab so you can put down a beat, and record it into SLab. This would potentially be via the effects send/returns, you would attach a drum to a send bus, or perhaps just via the data API into the diskfile. A couple of synths would be interesting as well, especially a decent Hammond box, but that would bring me back to MIDI again! WaveSLab needs some work as well. I would like to add timestretch and pitchshift controls, and work on the cut and paste controls. What I would like WaveSLab to do is be a complete librarian rather than a song editor. It should support some form of "play lists" where samples, riffs and beats could be chained together and then played out via the mixer. This would reduce disk space requirements at the expense of extra memory and CPU operations.
Finally at some point I want to make SLab work in real time. At the moment it only really mixes from tracks on a disk. I intend to allow it to mix from up to 16 inputs to the same number of outputs with all the filtering and in-line effects. This is actually quite a lot of work, and will require a serious CPU.
Other Technical Info from the current Readme...
MixSLab ------- A suite of applications for direct to disk digital audio recording, mixing and signal manipulation. MixSLab itself is a launchpad for the remaining applications. The applications themselves may consists of several programmes and/or processes. StudioSLab ---------- Maximum configuration: (see below for more realistic operational limitations) 64 Tracks. 16 Send/Return busses (8 pre fader, 8 post fader). 4 Stereo busses. 8 audio devices, 44.1kHz, 16 bit stereo, provides 16 inputs and outputs. Each Track: Input device select. Output device select. Input gain. PreSends, with bus selection. Dynamics Section, 6 algorithms, with optional bypass: NoiseGate: Gate signal on threshold with AD envelope. Compressor: Gate signal, and force to fixed gain with ADSR envelope. Compressor2: Same algorithm with preloaded attack. Limitor: Limit excess signal level. Limitor2: Gate signal, limit excess signal level with ADSR envelope. Compander: Gate signal, expand low level signal with ADSR envelope. Digital Filter (DDF) Section, 7 algorithms with optional bypass: EQ: HI Gain, LO Gain. EQ: HI Cutoff and Gain, LO Cutoff and Gain. EQ: HI Cutoff/Gain/Feedback, LO Cutoff/Gain/Feedback. BandPass: gain, frequency and Q controls. Notch: gain, frequency and Q controls. EQ: Hi/Lo gain and frequency, dual pole. EQ: Hi/Lo gain and cutoff, parametric Mid control of Freq/Gain/Q. Digial In-line Effects: Chorus Reverb Echo Delay PostSends, with bus selection. Stereo panning. Mute. Solo. Boost (6 dB signal gain). Stereo Bus Selection (grouping). Volume Fader. Track notes scratchpad. 16 Return Busses: Volume control, up to +6dB return signal. Left, Right controls. Output Device Selection to any of the 8 available audio devices. Effects attachments, with effects chaining. Bus bypass, effects bypass options. 4 Stereo Busses: Volume pot, Left, Right fader controls. VU Meters: 16 independant fully configurable VUs. Simultaneous peak and RMS display. Sources: any input, left or right, any output, left or right, any track, pre or post dynamics/EQ/FX. Master Controls: MasterVolume. Master Left, Right controls. Dynamic Digital Filter per L/R. MicroMix: OSS audio device options controller. EffectSLab ---------- This is a set of DSP algorithms running as modules, with the "EffectSLab" being a 19 inch rack window. The Following algorithms are available: Echo - configurable delay, decay and feedback. Reverb - Spread, depth and feedback - hall/room type effect. Streverb - Spread, depth and feedback - Stereo hall/room type effect. Streverb2 - Spread, depth and feedback - Stereo hall/room alternate algo. Chambre - Stereo reverb, filtering/damping, early/late reflect controls. Chorus - configurable speed and breadth. stChorus - Stereo chorus, configurable speed and breadth. stNewAPIChorus - Same as above, but uses alternative API definitions. Flanger - Speed and breadth. Phaser - Speed, depth, feedback, Max and Q parameters. MultiTap - Spread, depth and feedback. Delay line with 4 taps. Spacial - The MultiTap algo, 4 tap delay line, with each tap at a configurable delay and level. Spacial2 - Stereo MultiTap algo, 4 tap delay line, with each tap at a configurable delay and level, taps 1 and 3 left, 2 and 4 right. Rotary - Stereo rotary speaker algorithm. Overotary - Stereo rotary speaker with vanzeggelaars valve overdrive algorithm mixed in for full rotary speaker simulation. Leslie - Full stereo rotary speaker algorithm and frontend. Limitor - Limit, Factor. Simple excess signal compression. Limitor2 - Sensitivity/Threshold/Attack, Sensitivity/Threshold/Decay Level/Factor params, gated limitor algorithm. NoiseGate - Sensitivity/Threshold/Attack, Sensitivity/Threshold/Decay gating algorithm. Compressor - Sensitivity/Threshold/Attack, Sensitivity/Threshold/Decay and signal Level params. stcompressor - Stereo Compressor Sciompressor - Filtered sidechain input gating compressor. and signal Level params. Ducker - Duck main input based on filtered sidechain input. Distortion - Speaker distortion algorithm, very noisy. OverDrive - VanZeggelaars valve overdrive, 2 algorithms of creamy valve distortion and one transitor algo with control over input bias and gain. BlueValve - VanZeggelaars creamy valve overdrive, with 3 bands of active EQ. BlueValveIt - Bluevalve with extended user interface and user memories. Equalizer - 8 band equalizer, with SLab user interface. Stereographic - 8 band stereo graphic equalizer with spectral analyser. DimensionC - MultiTapped "helicopter" flanger. DimensionD - Stereo MultiTapped flanger, with feedback. Most effects use the integral user interface definitions. APIs are provided for creation of new effects. Source code of the echo, flanger and stereo chorus are provided as examples using the API. Most of the effects are mono, but stereo support is provided in the APIs via ability to register for multiple busses (see source for stereo chorus). There are hooks available to allow the effects code itself to generate the values displayed in the GUI. This allows the effect to indicate literal values and parameter units in the display. The StereoGraphic, Leslie and BlueValveIt use their own interface: The effects API provides for the capacity to allow the effect to only link into the data stream for a given bus, but decline to use the GUI. To programme with this method, do not add any controllers during effect init. The engine will interupt the effect (SIGUSR1) when data is available on the bus, allowing asynchronous notification of user data availability. As yet there are no example sources for how this can be achieved, this will be remedied in the next release. If you have questions, send an EMail. These external effects are not under control of mixdown session recording, since they are outside of the SLab control. They do however have memories, 4 locations each, and the memories are saved per song in the dataBase directory for that song. This allows configurations to be saved and retrieved between mixing sessions, so the same mix can be recovered. WaveSLab -------- Visual wave/sample editor, operates on multiple tracks or with multiple waveSLabs. Tools will operate on tracks or selections, with tooling for: cut copy paste undo merge gain normalise reverse fade erase import export loop Interface implements drag and drop operations. Full suite of "undo" options so edits are non-destructive. Full status bars and floating menus. Implements sample zooming, on-line magnification rotary controls for sample inspection, and a wave scrolling mechanism. Zero crossing search algorithm for 'deglitched' sample looping. Full Bar and Beat editing is possible, with selection "snapping" to metronome pulses. The mouse can be used to highlight sections of each wave, and the edit tools can be applied to the highlighted waves, in turn to each wave in the SLab if desired. Any number of tracks can be loaded into a single WaveSLab using the add buttons, or by dragging a track to this SLab. Multiple WaveSLabs may be opened seperately, operating on the same track if useful. It is possible to zoom in "sub sample" level, where each sample becomes a visible bar in the wavemeter. At this point it is possible to paint waves freehand using the Meta key and Button1, to either generate new waves or clean up existing ones. Each WaveSLab wavemeter has a status bar indicating the sample and its value currently under the pointer, SMPTE offset of sample (in the current SMPTE format), selection start and end points, etc. TapeSLab -------- Tape Controls: Stop, Play, Forward, Rewind, SessionRecord, SessionPlay. SearchForward, SearchReverse, Pause, Record/Pause, Punch In/Out. Micro Tunable tape run speed. Track control menus. MixDown Session Recording facilities - continuous controller automation. 8 memory locations for tape positioning. Full LCD SMPTE display of current location, memory locations and status. SMPTE tape counters 24, 25 and 30 fps display (29.97 will also be included when SMPTE synchronisation is implemented). The SMPTE format used by the TapeSLab is mm:ss:ff. There are 3 buttons per memory location. A Select button, used to select this memory for search forward and search backward (the search buttons just spool the tape to the next active memory location). A Set button which transfers the current tape spool position to the given memory location, and a Clear button, used to clear the given location. The memory locations are saved in the baseline file. SessionRecord and SessionPlay control the recording not of audio data, but of changes to the studio continuous controllers. As a song is "SessionRecorded", any changes made to volumes, pans etc, during the duration of the playing are saved to the session recording code. The SessionPlay can then be used to replay the dynamic mix. It is not intended to do audio recording and session recording simultaneously, although it should be possible. These features should really be used from the start of the tape, but may work at arbitrary points. DeviceSLab ---------- Manages all the options of the OSS configured devices. The Studio MicroMixer alters all the devices in unison. This slab will give access to each device independently for independent alteration of device parameters. This slab was introduced with support for multiple duplex audio devices - the MicroMixer section could not support these features. It is possible to configure the StudioSLab and DeviceSLob NOT to manage the controllers of any given device. This is done in the "File->StudioFiles..." menu, with the "NoControls" button. In this mode any changes made to the mix for a device will be declined by the audio device libraries. This will allow a user to configure the audio device with a third party application such as tkmix. General Information ------------------- The mixing desk is split into 3 main areas. The mixing section, bussing section and mastering section. The mixing section is for the tracks, the bussing manages the effects returns and stereo bus groups, and the mastering section is the final level controls, and output device controls. User interface is TCL/TK, with widget extensions for potmeters (rotary controls) VU meters, and wave editors. The mixing desk can be split into master controls and track controls (for low res monitors), and the volume slider length can be tuned. The actual track pane is scrollable to allow x out of y tracks to be shown simultaneously. Interface uses, where possible, drag and drop to be able to attach tracks to effects, effects to busses, to copy tracks between each other, to apply editing facilities etc. All interface parameters for a given mixdown can be saved to a config file for later retrieval. By "all" I mean volumes, filters, bus selections, active effects, effect parameters, VU meter selections, track notes etc. Multiple "baseline" mixes can be saved. The intention is to be able to recall the exact same sound and interface configuration between two mixing sessions. Similarly, controllers can be automated using "Mixdown Session Recording". This feature allows the changes in the continuous controllers (potmeters, sliders) to be recorded, replayed, and saved, providing dynamic mixes to be created. There is also one default mixdown file, and the ability to save multiple mixes per track. The stereo busses allow for track groupings, where multiple tracks can be sent to a stereo bus, and then controlled for their volumes and panning as a "group" of tracks. This is effective, but somewhat different from ganging, where multiple volume sliders can be controlled collectively. That latter may be implemented at a later date, but extensions to the stereo bussing is more likely since it is more flexible. The StudioSLab supports 8 completely independant full stereo mixes, although only one is via the main mixing desk, which uses the first output device. The rest are built using the effects send busses, and linking the returns into one of the other audio devices. Design Contraints ----------------- The 1.0 release was developed on a Pentium 133/16MB to the following specs: 16 tracks at 22050Hz, 16bit, 2 active effects. 8 tracks at 44100Hz, 16bit, 2 active effects. The above design contraints were roughly met. The 8 track full speed results in a maxing out of the CPU, but no noticable "ticking" of the signal. This has been accepted, even though it leaves little headroom for other operations, since the original design spec did not include the full bussing options, nor the DDFs, nor the multiple output devices. Even if filtering and bussing is disabled, there are a number of checks required in the code which increase overhead, and force the CPU loading up. Using fewer active tracks will allow more effects or filters to be active. The software should reasonably allow, for example, 8 out of 16 tracks to be active simultaniously. The bottleneck is CPU based, and bound to sample processing, not really disk IO based. This should allow for some extensive multitracking, and really becomes useful when mixdown session recording is used. Mixdown Session Recording is the capacity to record and replay controller changes in the StudioSLab in real time. The above design constraints are for the 1.0 code release. Later releases will negatively affect the above limits. A set of stripped mix algorithms are available which should run to about 16 CD tracks or 32 track at 22kHz, but do not implemented effects or filters. There are no performance guidelines for later software releases, and it can be expected that as functionality increases, the CPU demands will similarly be higher. There will be a garantee that the above performance measurements will be available in backward compatibility - the same mix algorithms will be provided in each release, and new functionality will be put into new algorithms. If the user is willing to sacrifice performance, the new functionality can be selected. [Some performance hits have been taken to allow for 8 duplex audio devices. This is in device window management and error checking, plus a rather large hit on the mixiod when recording several inputs. Similarly the enhancements for FX Chaining has had comsequences for performance. The existing algorithms should not be affected, only duplex3 and submixAlgo5] Implementation -------------- The basic application consists of several cooperating processes. Firstly the GUI, then the engine. The engine spawns the mixengine, which in turn spawns a disk IO daemon, and one audio input/output daemon per physical device. IPC is with shared memory, allowing data sharing between the processes (reduces overheads). Each sound effect is a seperate process which uses the API to connect to the relevant SHMEM segments, and requests services of the GUI for effect controls. The process based architecture prevents blocking of the mix algorithm on IO operations, and lends itself to a multiprocessor hardware platform. MultiStaged buffering is used to limit effects of context switching in a multiuser environment. The Mix Engine does the actual horsework for the application suite. It consists, as explained, of several processes communicating via shared memory. There is one main control process called the engine which creates a global control buffer. On request of signals it will create the mixengine which runs the signal processing code. This creates the shared disk buffer, and spawns the mixiod. Then shared audio IO buffers are generated, and creation of the audio IO daemons takes place. The data is read from the disk, and mixed according to the GUI parameters (the GUI only really interfaces to the shared memory control buffer), providing all necessary signal levels to each of the busses. It then sums the busses onto their respective audio IO shared memory segment. In addition to the mixing, the mixengine also generates some typical analogue "signal distortions". There are algorithms for crosstalk, wow/flutter and vinyl scratch which can be applied in varying amounts. The intention here is to remove the typically "clinical" feel of digitally recorded audio by applying analogous inaccuracies that are pleasing to the ear. These can of course all be disabled as required, and in how far the are pleasing or annoying depends on the listener. Crosstalk eats CPU cycles, since we need to proactively scan each track a couple more times. The Scratch implements a few different algorithms, giving mono scratch (equal amounts of same signal in each channel), stereo (complete signal diffusion) and a hybrid of the two, where only certain scratches hit both channels simulaneously. SYSTEM REQUIREMENTS ------------------- This runs and was developed on a P133 16 MB system. Get gobs of disk space if you want to do some real recording, 16 tracks CD quality requires about 80MB a minute. Compression can be applied to reduce this requirement by up to a factor of 4, at a consequent loss of signal quality since the compression algorithms are as of this release (2.0) all lossy. In addition, if new songs are created with a minimum of predefined run time (5 or 10 seconds) then autoextension on the Linux filesystem will only write new track sections. The consequence is, if you define 16 track, but only ever use 8 simultaneously then the disk space requirements will only be half of the total (and processing capacity is spared). Session recording will allow you to fade tracks in and out as you need them. Linux: IPC SHMEM required in kernel. Software was compiled on a 2.1.24 kernel, and full duplex may require this kernel. OSS 3.8-beta2. The software will run on a 2.0 kernel, with OSS 3.5.X, but duplex is unlikely to work without 2 soundcards (or sound devices). NOTE Since the release of this readme Slab 2.30 has been partially tested with the ALSA drivers and kernel 2.2.5 and seems to work fine. Read what Jaroslav Kysela has to say about the ALSA driver project.