Advanced Linux Sound Architecture

SEQUENCER

4.1 MIDI emulation

Software should know which standard is using (GM, GS, MT-32, XG). Emulation should be set/get from/to application and driver should offer only some emulation for internal synthesizer.

If there is a need to, we can even add a parameter to set the minimum and maximum number of voices to be allocated for a specific channel (like the Partial Reserve feature offered by Roland Synthesizers). Set the max. to 1 to get a monophonic channel, set it to 0 to essentially mute the channel.

The Drum/Percussive channel can default to 10 (GM compatible), but should be user configurable. The user should be able to set it to any channel he or she want, and even switch it off. Conforming GS/XG standards, multiple (eg. 3) drum maps can be provided.

For changing the voice allocation and drum parameters we can simple use NRPNs or sysex!!!

4.1.1 Channel mapping

Internal devices that have the capability to produce more that 16 distinct sounds at a time (this is sometimes called 'multi timbral') should not be restricted to just 16 voices because a MIDI port only support 16 channels. This limitation that is dictated by the MIDI standard can be overcome to give the device more than one port. If for instance a device is given 2 input ports, 32 MIDI channels can be addressed. More ports can be added if needed.

4.1.2 Wavetable synth

4.1.3 Sample format

A different (native) format for each type of wavetable synth could be a good idea to allow users to access all functionality of their synthesizer. Think of .pat for the Gravis Ultrasound cards, and a .sf2 format for the SoundBlaster AWE cards.

For better compatibility across synthesizers it is a good idea to use an uniform format for downloading samples. This format should provide the capability to download more advanced parameters for defining the 'patch'. Only a simple waveform won't be sufficient. The format should be able to handle splits, layers, envelopes, lfo's, vca's, filters etc. To get the requirements of parameters that we have to be able to specify we also have to take into account the capabilities of hardware samples (AKAI, Ensoniq, Emu, Roland etc.) and the sample format for the various mod players (669, MOD, Multitracker (MTM), Scream Tracker III (S3M), Ultratracker (ULT), FastTracker (XM) etc.)

Existing 'standard' formats have to be checked for their suitability for this application. Candidates could be:

GUS Patch format
RIFF WAVE samples/instruments
AIFF samples
SDS (MIDI Sample Dump standard) -> only support for wave data and loop point?
????

If no existing format exists yet, I'm afraid yet another file format will be defined. Perhaps the existing tagged file formats allow to build upon.

The most feasible option it this time looks to be choosing a 2-fold strategy:

All drivers support GUS Patch format. Though this is a limited format, it is better than having no standard at all.
Native, audio device specific format. This can be used to access all the bells and whistles a patch can be made off. It does not have to be audio data, it can as well be DSP code or synth parameters (sysex).

Version 0.036, April 2nd, 1999	Usage:
Copyright (c) 1998 by Frank van de Pol, Netherlands	Advanced Linux Sound Architecture