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. 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. Bus bypass option. 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. 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. 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. 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 optional 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. 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). NOTES ----- If the mixengine crashes, it tends to leave SHMEM stubs hanging around in the system, and it does not like this when restarted. Use "ipcs -m" and "ipcrm shm" to get rid of these segments. Please report process crashes so they can be fixed.