| LinuxSampler Developers | C. Schoenebeck, Ed. |
| Internet-Draft | LinuxSampler.org |
| Intended status: Informational | March 11, 2019 |
| Expires: September 12, 2019 |
LinuxSampler Control Protocol
LSCP 1.7
The LinuxSampler Control Protocol (LSCP) is an application-level protocol primarily intended for local and remote controlling the LinuxSampler backend application, which is a sophisticated server-like console application essentially playing back audio samples and manipulating the samples in real time to certain extent.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
This protocol is always case-sensitive if not explicitly claimed the opposite.
In examples, "C:" and "S:" indicate lines sent by the client (front-end) and server (LinuxSampler) respectively. Lines in examples must be interpreted as every line being CRLF terminated (carriage return character followed by line feed character as defined in the ASCII standard [RFC20]), thus the following example:
must actually be interpreted as client sending the following message:
where <CR> symbolizes the carriage return character and <LF> the line feed character as defined in the ASCII standard.
Due to technical reasons, messages can arbitrary be fragmented, means the following example:
could also happen to be sent in three messages like in the following sequence scenario:
where again <CR> and <LF> symbolize the carriage return and line feed characters respectively.
LSCP will certainly be extended and enhanced by-and-by. Each official release of the LSCP specification will be tagged with a unique version tuple. The version tuple consists at least of a major and minor version number like:
In this example the major version number would be "1" and the minor version number would be "2". Note that the version tuple might also have more than two elements. The major version number defines a group of backward compatible versions. That means a frontend is compatible to the connected sampler if and only if the LSCP versions to which each of the two parties complies to, match both of the following rules:
Compatibility:
Compatibility can only be claimed if both rules are true. The frontend can use the "GET SERVER INFO" [GET SERVER INFO] command to get the version of the LSCP specification the sampler complies with.
LinuxSampler is a so called software sampler application capable to playback audio samples from a computer's Random Access Memory (RAM) as well as directly streaming it from disk. LinuxSampler is designed to be modular. It provides several so called "sampler engines" where each engine is specialized for a certain purpose. LinuxSampler has virtual channels which will be referred in this document as "sampler channels". The channels are in such way virtual as they can be connected to an arbitrary MIDI input method and arbitrary MIDI channel (e.g. sampler channel 17 could be connected to an ALSA sequencer device 64:0 and listening to MIDI channel 1 there). Each sampler channel will be associated with an instance of one of the available sampler engines (e.g. GigEngine, DLSEngine). The audio output of each sampler channel can be routed to an arbitrary audio output method (ALSA / JACK) and an arbitrary audio output channel there.
Main focus of this protocol is to provide a way to configure a running LinuxSampler instance and to retrieve information about it. The focus of this protocol is not to provide a way to control synthesis parameters or even to trigger or release notes. Or in other words; the focus are those functionalities which are not covered by MIDI or which may at most be handled via MIDI System Exclusive Messages.
There are two distinct methods of communication between a running instance of LinuxSampler and one or more control applications, so called "front-ends": a simple request/response communication method used by the clients to give commands to the server as well as to inquire about server's status and a subscribe/notify communication method used by the client to subscribe to and receive notifications of certain events as they happen on the server. The latter needs more effort to be implemented in the front-end application. The two communication methods will be described next.
This simple communication method is based on TCP [RFC793]. The front-end application establishes a TCP connection to the LinuxSampler instance on a certain host system. Then the front-end application will send certain ASCII based commands as defined in this document (every command line must be CRLF terminated - see "Conventions used in this document" at the beginning of this document) and the LinuxSampler application will response after a certain process time with an appropriate ASCII based answer, also as defined in this document. So this TCP communication is simply based on query and answer paradigm. That way LinuxSampler is only able to answer on queries from front-ends, but not able to automatically send messages to the client if it's not asked to. The fronted should not reconnect to LinuxSampler for every single command, instead it should keep the connection established and simply resend message(s) for subsequent commands. To keep information in the front-end up-to-date the front-end has to periodically send new requests to get the current information from the LinuxSampler instance. This is often referred to as "polling". While polling is simple to implement and may be OK to use in some cases, there may be disadvantages to polling such as network traffic overhead and information being out of date. It is possible for a client or several clients to open more than one connection to the server at the same time. It is also possible to send more than one request to the server at the same time but if those requests are sent over the same connection server MUST execute them sequentially. Upon executing a request server will produce a result set and send it to the client. Each and every request made by the client MUST result in a result set being sent back to the client. No other data other than a result set may be sent by a server to a client. No result set may be sent to a client without the client sending request to the server first. On any particular connection, result sets MUST be sent in their entirety without being interrupted by other result sets. If several requests got queued up at the server they MUST be processed in the order they were received and result sets MUST be sent back in the same order.
Result set could be one of the following types:
Warning and Error result sets MUST be single line and have the following format:
Where <warning-code> and <error-code> are numeric unique identifiers of the warning or error and <warning-message> and <error-message> are human readable descriptions of the warning or error respectively.
Examples:
Normal result sets could be:
Empty result set is issued when the server only needed to acknowledge the fact that the request was received and it was processed successfully and no additional information is available. This result set has the following format:
Example:
Single line result sets are command specific. One example of a single line result set is an empty line. Multi-line result sets are command specific and may include one or more lines of information. They MUST always end with the following line:
Example:
In addition to above mentioned formats, warnings and empty result sets MAY be indexed. In this case, they have the following formats respectively:
where <index> is command specific and is used to indicate channel number that the result set was related to or other integer value.
Each line of the result set MUST end with <CRLF>.
Examples:
This more sophisticated communication method is actually only an extension of the simple request/response communication method. The front-end still uses a TCP connection and sends the same commands on the TCP connection. Two extra commands are SUBSCRIBE and UNSUBSCRIBE commands that allow a client to tell the server that it is interested in receiving notifications about certain events as they happen on the server. The SUBSCRIBE command has the following syntax:
where <event-id> will be replaced by the respective event that client wants to subscribe to. Upon receiving such request, server SHOULD respond with OK and start sending EVENT notifications when a given even has occurred to the front-end when an event has occurred. It MAY be possible certain events may be sent before OK response during real time nature of their generation. Event messages have the following format:
where <event-id> uniquely identifies the event that has occurred and <custom-event-data> is event specific.
Several rules must be followed by the server when generating events:
If the client is not interested in a particular event anymore it MAY issue UNSUBSCRIBE command using the following syntax:
where <event-id> will be replace by the respective event that client is no longer interested in receiving. For a list of supported events see Section 8.
Example: the fill states of disk stream buffers have changed on sampler channel 4 and the LinuxSampler instance will react by sending the following message to all clients who subscribed to this event:
Which means there are currently three active streams on sampler channel 4, where the stream with ID "35" is filled by 62%, stream with ID 33 is filled by 80% and stream with ID 37 is filled by 98%.
Clients may choose to open more than one connection to the server and use some connections to receive notifications while using other connections to issue commands to the back-end. This is entirely legal and up to the implementation. This does not change the protocol in any way and no special restrictions exist on the server to allow or disallow this or to track what connections belong to what front-ends. Server will listen on a single port, accept multiple connections and support protocol described in this specification in it's entirety on this single port on each connection that it accepted.
Due to the fact that TCP is used for this communication, dead peers will be detected automatically by the OS TCP stack. While it may take a while to detect dead peers if no traffic is being sent from server to client (TCP keep-alive timer is set to 2 hours on many OSes) it will not be an issue here as when notifications are sent by the server, dead client will be detected quickly.
When connection is closed for any reason server MUST forget all subscriptions that were made on this connection. If client reconnects it MUST resubscribe to all events that it wants to receive.
This chapter will describe the available control commands that can be sent on the TCP connection in detail. Some certain commands (e.g. "GET CHANNEL INFO" [GET CHANNEL INFO] or "GET ENGINE INFO" [GET ENGINE INFO]) lead to multiple-line responses. In this case LinuxSampler signals the end of the response by a "." (single dot) line.
White lines, that is lines which only contain space and tabulator characters, and lines that start with a "#" character are ignored, thus it's possible for example to group commands and to place comments in a LSCP script file.
Instances of drivers in LinuxSampler are called devices. You can use multiple audio devices simultaneously, e.g. to output the sound of one sampler channel using the ALSA audio output driver, and on another sampler channel you might want to use the JACK audio output driver. For particular audio output systems it's also possible to create several devices of the same audio output driver, e.g. two separate ALSA audio output devices for using two different sound cards at the same time. This chapter describes all commands to configure LinuxSampler's audio output devices and their parameters.
Instead of defining commands and parameters for each driver individually, all possible parameters, their meanings and possible values have to be obtained at runtime. This makes the protocol a bit abstract, but has the advantage, that front-ends can be written independently of what drivers are currently implemented and what parameters these drivers are actually offering. This means front-ends can even handle drivers which are implemented somewhere in future without modifying the front-end at all.
Note: examples in this chapter showing particular parameters of drivers are not meant as specification of the drivers' parameters. Driver implementations in LinuxSampler might have complete different parameter names and meanings than shown in these examples or might change in future, so these examples are only meant for showing how to retrieve what parameters drivers are offering, how to retrieve their possible values, etc.
Use the following command to get the number of audio output drivers currently available for the LinuxSampler instance:
Possible Answers:
Example:
Use the following command to list all audio output drivers currently available for the LinuxSampler instance:
Possible Answers:
Example:
Use the following command to get detailed information about a specific audio output driver:
Where <audio-output-driver> is the name of the audio output driver, returned by the "LIST AVAILABLE_AUDIO_OUTPUT_DRIVERS" [LIST AVAILABLE_AUDIO_OUTPUT_DRIVERS] command.
Possible Answers:
Example:
Use the following command to get detailed information about a specific audio output driver parameter:
Where <audio> is the name of the audio output driver as returned by the "LIST AVAILABLE_AUDIO_OUTPUT_DRIVERS" [LIST AVAILABLE_AUDIO_OUTPUT_DRIVERS] command, <prm> a specific parameter name for which information should be obtained (as returned by the "GET AUDIO_OUTPUT_DRIVER INFO" [GET AUDIO_OUTPUT_DRIVER INFO] command) and <deplist> is an optional list of parameters on which the sought parameter <prm> depends on, <deplist> is a list of key-value pairs in form of "key1=val1 key2=val2 ...", where character string values are encapsulated into apostrophes ('). Arguments given with <deplist> which are not dependency parameters of <prm> will be ignored, means the front-end application can simply put all parameters into <deplist> with the values already selected by the user.
Possible Answers:
The mentioned fields above don't have to be in particular order.
Examples:
Use the following command to create a new audio output device for the desired audio output system:
Where <audio-output-driver> should be replaced by the desired audio output system as returned by the "LIST AVAILABLE_AUDIO_OUTPUT_DRIVERS" [LIST AVAILABLE_AUDIO_OUTPUT_DRIVERS] command and <param-list> by an optional list of driver specific parameters in form of "key1=val1 key2=val2 ...", where character string values should be encapsulated into apostrophes ('). Note that there might be drivers which require parameter(s) to be given with this command. Use the previously described commands in this chapter to get this information.
Possible Answers:
Examples:
Use the following command to destroy a created output device:
Where <device-id> should be replaced by the numerical ID of the audio output device as given by the "CREATE AUDIO_OUTPUT_DEVICE" [CREATE AUDIO_OUTPUT_DEVICE] or "LIST AUDIO_OUTPUT_DEVICES" [LIST AUDIO_OUTPUT_DEVICES] command.
Possible Answers:
Example:
Use the following command to count all created audio output devices:
Possible Answers:
Example:
Use the following command to list all created audio output devices:
Possible Answers:
Example:
Use the following command to get current settings of a specific, created audio output device:
Where <device-id> should be replaced by numerical ID of the audio output device as e.g. returned by the "LIST AUDIO_OUTPUT_DEVICES" [LIST AUDIO_OUTPUT_DEVICES] command.
Possible Answers:
LinuxSampler will answer by sending a <CRLF> separated list. Each answer line begins with the information category name followed by a colon and then a space character <SP> and finally the info character string to that info category. As some parameters might allow multiple values, character strings are encapsulated into apostrophes ('). At the moment the following information categories are defined (independently of device):
The mentioned fields above don't have to be in particular order. The fields above are only those fields which are returned by all audio output devices. Every audio output driver might have its own, additional driver specific parameters (see Section 6.2.3) which are also returned by this command.
Example:
Use the following command to alter a specific setting of a created audio output device:
Where <device-id> should be replaced by the numerical ID of the audio output device as given by the "CREATE AUDIO_OUTPUT_DEVICE" [CREATE AUDIO_OUTPUT_DEVICE] or "LIST AUDIO_OUTPUT_DEVICES" [LIST AUDIO_OUTPUT_DEVICES] command, <key> by the name of the parameter to change and <value> by the new value for this parameter.
Possible Answers:
Example:
Use the following command to get information about an audio channel:
Where <device-id> is the numerical ID of the audio output device as given by the "CREATE AUDIO_OUTPUT_DEVICE" [CREATE AUDIO_OUTPUT_DEVICE] or "LIST AUDIO_OUTPUT_DEVICES" [LIST AUDIO_OUTPUT_DEVICES] command and <audio-chan> the audio channel number.
Possible Answers:
The mentioned fields above don't have to be in particular order. The fields above are only those fields which are generally returned for the described cases by all audio channels regardless of the audio driver. Every audio channel might have its own, additional driver and channel specific parameters.
Examples:
Use the following command to get detailed information about specific audio channel parameter:
Where <dev-id> is the numerical ID of the audio output device as returned by the "CREATE AUDIO_OUTPUT_DEVICE" [CREATE AUDIO_OUTPUT_DEVICE] or "LIST AUDIO_OUTPUT_DEVICES" [LIST AUDIO_OUTPUT_DEVICES] command, <chan> the audio channel number and <param> a specific channel parameter name for which information should be obtained (as returned by the "GET AUDIO_OUTPUT_CHANNEL INFO" [GET AUDIO_OUTPUT_CHANNEL INFO] command).
Possible Answers:
Example:
Use the following command to alter a specific setting of an audio output channel:
Where <dev-id> should be replaced by the numerical ID of the audio output device as returned by the "CREATE AUDIO_OUTPUT_DEVICE" [CREATE AUDIO_OUTPUT_DEVICE] or "LIST AUDIO_OUTPUT_DEVICES" [LIST AUDIO_OUTPUT_DEVICES] command, <chn> by the audio channel number, <key> by the name of the parameter to change and <value> by the new value for this parameter.
Possible Answers:
Example:
Instances of drivers in LinuxSampler are called devices. You can use multiple MIDI devices simultaneously, e.g. to use MIDI over ethernet as MIDI input on one sampler channel and ALSA as MIDI input on another sampler channel. For particular MIDI input systems it's also possible to create several devices of the same MIDI input type. This chapter describes all commands to configure LinuxSampler's MIDI input devices and their parameters.
Instead of defining commands and parameters for each driver individually, all possible parameters, their meanings and possible values have to be obtained at runtime. This makes the protocol a bit abstract, but has the advantage, that front-ends can be written independently of what drivers are currently implemented and what parameters these drivers are actually offering. This means front-ends can even handle drivers which are implemented somewhere in future without modifying the front-end at all.
Commands for configuring MIDI input devices are pretty much the same as the commands for configuring audio output drivers, already described in the last chapter.
Note: examples in this chapter showing particular parameters of drivers are not meant as specification of the drivers' parameters. Driver implementations in LinuxSampler might have complete different parameter names and meanings than shown in these examples or might change in future, so these examples are only meant for showing how to retrieve what parameters drivers are offering, how to retrieve their possible values, etc.
Use the following command to get the number of MIDI input drivers currently available for the LinuxSampler instance:
Possible Answers:
Example:
Use the following command to list all MIDI input drivers currently available for the LinuxSampler instance:
Possible Answers:
Example:
Use the following command to get detailed information about a specific MIDI input driver:
Where <midi-input-driver> is the name of the MIDI input driver as returned by the "LIST AVAILABLE_MIDI_INPUT_DRIVERS" [LIST AVAILABLE_MIDI_INPUT_DRIVERS] command.
Possible Answers:
Example:
Use the following command to get detailed information about a specific parameter of a specific MIDI input driver:
Where <midit> is the name of the MIDI input driver as returned by the "LIST AVAILABLE_MIDI_INPUT_DRIVERS" [LIST AVAILABLE_MIDI_INPUT_DRIVERS] command, <param> a specific parameter name for which information should be obtained (as returned by the "GET MIDI_INPUT_DRIVER INFO" [GET MIDI_INPUT_DRIVER INFO] command) and <deplist> is an optional list of parameters on which the sought parameter <param> depends on, <deplist> is a key-value pair list in form of "key1=val1 key2=val2 ...", where character string values are encapsulated into apostrophes ('). Arguments given with <deplist> which are not dependency parameters of <param> will be ignored, means the front-end application can simply put all parameters in <deplist> with the values selected by the user.
Possible Answers:
LinuxSampler will answer by sending a <CRLF> separated list. Each answer line begins with the information category name followed by a colon and then a space character <SP> and finally the info character string to that info category. There is information which is always returned, independent of the given driver parameter and there is optional information which is only shown dependent to given driver parameter. At the moment the following information categories are defined:
The mentioned fields above don't have to be in particular order.
Example:
Use the following command to create a new MIDI input device for the desired MIDI input system:
Where <midi-input-driver> should be replaced by the desired MIDI input system as returned by the "LIST AVAILABLE_MIDI_INPUT_DRIVERS" [LIST AVAILABLE_MIDI_INPUT_DRIVERS] command and <param-list> by an optional list of driver specific parameters in form of "key1=val1 key2=val2 ...", where character string values should be encapsulated into apostrophes ('). Note that there might be drivers which require parameter(s) to be given with this command. Use the previously described commands in this chapter to get that information.
Possible Answers:
Example:
Use the following command to destroy a created MIDI input device:
Where <device-id> should be replaced by the device's numerical ID as returned by the "CREATE MIDI_INPUT_DEVICE" [CREATE MIDI_INPUT_DEVICE] or "LIST MIDI_INPUT_DEVICES" [LIST MIDI_INPUT_DEVICES] command.
Possible Answers:
Example:
Use the following command to count all created MIDI input devices:
Possible Answers:
Example:
Use the following command to list all created MIDI input devices:
Possible Answers:
Examples:
Use the following command to get current settings of a specific, created MIDI input device:
Where <device-id> is the numerical ID of the MIDI input device as returned by the "CREATE MIDI_INPUT_DEVICE" [CREATE MIDI_INPUT_DEVICE] or "LIST MIDI_INPUT_DEVICES" [LIST MIDI_INPUT_DEVICES] command.
Possible Answers:
The mentioned fields above don't have to be in particular order. The fields above are only those fields which are returned by all MIDI input devices. Every MIDI input driver might have its own, additional driver specific parameters (see "GET MIDI_INPUT_DRIVER INFO" [GET MIDI_INPUT_DRIVER INFO] command) which are also returned by this command.
Example:
Use the following command to alter a specific setting of a created MIDI input device:
Where <device-id> should be replaced by the numerical ID of the MIDI input device as returned by the "CREATE MIDI_INPUT_DEVICE" [CREATE MIDI_INPUT_DEVICE] or "LIST MIDI_INPUT_DEVICES" [LIST MIDI_INPUT_DEVICES] command, <key> by the name of the parameter to change and <value> by the new value for this parameter.
Possible Answers:
Example:
Use the following command to get information about a MIDI port:
Where <device-id> is the numerical ID of the MIDI input device as returned by the "CREATE MIDI_INPUT_DEVICE" [CREATE MIDI_INPUT_DEVICE] or "LIST MIDI_INPUT_DEVICES" [LIST MIDI_INPUT_DEVICES] command and <midi-port> the MIDI input port number.
Possible Answers:
The field above is only the one which is returned by all MIDI ports regardless of the MIDI driver and port. Every MIDI port might have its own, additional driver and port specific parameters.
Example:
Use the following command to get detailed information about specific MIDI port parameter:
Where <dev-id> is the numerical ID of the MIDI input device as returned by the "CREATE MIDI_INPUT_DEVICE" [CREATE MIDI_INPUT_DEVICE] or "LIST MIDI_INPUT_DEVICES" [LIST MIDI_INPUT_DEVICES] command, <port> the MIDI port number and <param> a specific port parameter name for which information should be obtained (as returned by the "GET MIDI_INPUT_PORT INFO" [GET MIDI_INPUT_PORT INFO] command).
Possible Answers:
The mentioned fields above don't have to be in particular order.
Example:
Use the following command to alter a specific setting of a MIDI input port:
Where <device-id> should be replaced by the numerical ID of the MIDI device as returned by the "CREATE MIDI_INPUT_DEVICE" [CREATE MIDI_INPUT_DEVICE] or "LIST MIDI_INPUT_DEVICES" [LIST MIDI_INPUT_DEVICES] command, <port> by the MIDI port number, <key> by the name of the parameter to change and <value> by the new value for this parameter (encapsulated into apostrophes) or NONE (not encapsulated into apostrophes) for specifying no value for parameters allowing a list of values.
Possible Answers:
Example:
The following commands describe how to add and remove sampler channels, associate a sampler channel with a sampler engine, load instruments and connect sampler channels to MIDI and audio devices.
An instrument file can be loaded and assigned to a sampler channel by one of the following commands:
Where <filename> is the name of the instrument file on the LinuxSampler instance's host system, <instr-index> the index of the instrument in the instrument file and <sampler-channel> is the number of the sampler channel the instrument should be assigned to. Each sampler channel can only have one instrument.
Notice: since LSCP 1.2 the <filename> argument supports escape characters for special characters (see chapter "Character Set and Escape Sequences [character_set]" for details) and accordingly backslash characters in the filename MUST now be escaped as well!
The difference between regular and NON_MODAL versions of the command is that the regular command returns OK only after the instrument has been fully loaded and the channel is ready to be used while NON_MODAL version returns immediately and a background process is launched to load the instrument on the channel. The GET CHANNEL INFO [GET CHANNEL INFO] command can be used to obtain loading progress from INSTRUMENT_STATUS field. LOAD command will perform sanity checks such as making sure that the file could be read and it is of a proper format and SHOULD return ERR and SHOULD not launch the background process should any errors be detected at that point.
Possible Answers:
Example (Unix):
Example (Windows):
A sampler engine type can be associated to a specific sampler channel by the following command:
Where <engine-name> is an engine name as obtained by the "LIST AVAILABLE_ENGINES" [LIST AVAILABLE_ENGINES] command and <sampler-channel> the sampler channel as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command where the engine type should be assigned to. This command should be issued after adding a new sampler channel and before any other control commands on the new sampler channel. It can also be used to change the engine type of a sampler channel. This command has (currently) no way to define or force if a new engine instance should be created and assigned to the given sampler channel or if an already existing instance of that engine type, shared with other sampler channels, should be used.
Possible Answers:
Example:
The number of sampler channels can change on runtime. To get the current amount of sampler channels, the front-end can send the following command:
Possible Answers:
Example:
The number of sampler channels can change on runtime. To get the current list of sampler channels, the front-end can send the following command:
Possible Answers:
Example:
A new sampler channel can be added to the end of the sampler channel list by sending the following command:
This will increment the sampler channel count by one and the new sampler channel will be appended to the end of the sampler channel list. The front-end should send the respective, related commands right after to e.g. load an engine, load an instrument and setting input, output method and eventually other commands to initialize the new channel. The front-end should use the sampler channel returned by the answer of this command to perform the previously recommended commands, to avoid race conditions e.g. with other front-ends that might also have sent an "ADD CHANNEL" command.
Possible Answers:
Example:
A sampler channel can be removed by sending the following command:
Where <sampler-channel> should be replaced by the number of the sampler channel as given by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command. The channel numbers of all subsequent sampler channels remain the same.
Possible Answers:
Example:
The front-end can ask for the number of available engines by sending the following command:
Possible Answers:
Example:
The front-end can ask for a list of all available engines by sending the following command:
Possible Answers:
Example:
The front-end can ask for information about a specific engine by sending the following command:
Where <engine-name> is an engine name as obtained by the "LIST AVAILABLE_ENGINES" [LIST AVAILABLE_ENGINES] command.
Possible Answers:
The mentioned fields above don't have to be in particular order.
Examples:
The front-end can ask for the current settings of a sampler channel by sending the following command:
Where <sampler-channel> is the sampler channel number the front-end is interested in as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command.
Possible Answers:
The mentioned fields above don't have to be in particular order.
Example:
The front-end can ask for the current number of active voices on a sampler channel by sending the following command:
Where <sampler-channel> is the sampler channel number the front-end is interested in as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command.
Possible Answers:
Example:
The front-end can ask for the current number of active disk streams on a sampler channel by sending the following command:
Where <sampler-channel> is the sampler channel number the front-end is interested in as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command.
Possible Answers:
Example:
The front-end can ask for the current fill state of all disk streams on a sampler channel by sending the following command:
to get the fill state in bytes or
to get the fill state in percent, where <sampler-channel> is the sampler channel number the front-end is interested in as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command.
Possible Answers:
Examples:
The front-end can set the audio output device on a specific sampler channel by sending the following command:
Where <sampler-channel> is the respective sampler channel number as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command and <audio-device-id> is the numerical ID of the audio output device as given by the "CREATE AUDIO_OUTPUT_DEVICE" [CREATE AUDIO_OUTPUT_DEVICE] or "LIST AUDIO_OUTPUT_DEVICES" [LIST AUDIO_OUTPUT_DEVICES] command.
Possible Answers:
Examples:
DEPRECATED: THIS COMMAND WILL DISAPPEAR!
The front-end can alter the audio output type on a specific sampler channel by sending the following command:
Where <audio-output-type> is currently either "ALSA" or "JACK" and <sampler-channel> is the respective sampler channel number.
Possible Answers:
Examples:
Deprecated:
The front-end can alter the audio output channel on a specific sampler channel by sending the following command:
Where <sampler-chan> is the sampler channel number as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command, <audio-out> is the numerical ID of the sampler channel's audio output channel which should be rerouted and <audio-in> is the numerical ID of the audio channel of the selected audio output device where <audio-out> should be routed to.
Possible Answers:
Examples:
The front-end can add a MIDI input on a specific sampler channel by sending the following command:
Where <sampler-channel> is the sampler channel number as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command and <midi-device-id> is the numerical ID of the MIDI input device as returned by the "CREATE MIDI_INPUT_DEVICE" [CREATE MIDI_INPUT_DEVICE] or "LIST MIDI_INPUT_DEVICES" [LIST MIDI_INPUT_DEVICES] command, and <midi-input-port> is an optional MIDI input port number of that MIDI input device. If <midi-input-port> is omitted, then the MIDI input device's first port (port number 0) is used.
Possible Answers:
Examples:
Since:
The front-end can remove one ore more MIDI input(s) on a specific sampler channel by sending the following command:
Where <sampler-channel> is the sampler channel number as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command and <midi-device-id> and <midi-input-port> are optional numerical IDs defining the MIDI input device and one of its MIDI ports as returned by the "LIST CHANNEL MIDI_INPUTS" [LIST CHANNEL MIDI_INPUTS] command.
If <midi-input-port> is omitted, then all MIDI input ports of <midi-device-id> are disconnected from this sampler channel.
If both, <midi-device-id> and <midi-input-port> are omitted, then all MIDI input ports currently connected to this sampler channel are disconnected from this sampler channel.
Possible Answers:
Examples:
Since:
The front-end can query a list of all currently connected MIDI inputs of a certain sampler channel by sending the following command:
Where <sampler-channel> is the sampler channel number as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command.
Possible Answers:
Example:
Since:
DEPRECATED: THIS COMMAND WILL DISAPPEAR!
The front-end can set the MIDI input device on a specific sampler channel by sending the following command:
Where <sampler-channel> is the sampler channel number as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command and <midi-device-id> is the numerical ID of the MIDI input device as returned by the "CREATE MIDI_INPUT_DEVICE" [CREATE MIDI_INPUT_DEVICE] or "LIST MIDI_INPUT_DEVICES" [LIST MIDI_INPUT_DEVICES] command.
If more than 1 MIDI inputs are currently connected to this sampler channel: Sending this command will disconnect ALL currently connected MIDI input ports connected to this sampler channel before establishing the new MIDI input connection. So this command does NOT add the connection, it replaces all existing ones instead. This behavior is due to preserving full behavior backward compatibility.
Possible Answers:
Examples:
Deprecated:
DEPRECATED: THIS COMMAND WILL DISAPPEAR!
The front-end can alter the MIDI input type on a specific sampler channel by sending the following command:
Where <midi-input-type> is currently only "ALSA" and <sampler-channel> is the respective sampler channel number.
If more than 1 MIDI inputs are currently connected to this sampler channel: Sending this command will disconnect ALL currently connected MIDI input ports connected to this sampler channel before establishing the new MIDI input connection. So this command does NOT add the connection, it replaces all existing ones instead. This behavior is due to preserving full behavior backward compatibility.
Possible Answers:
Examples:
Deprecated:
DEPRECATED: THIS COMMAND WILL DISAPPEAR!
The front-end can alter the MIDI input port on a specific sampler channel by sending the following command:
Where <midi-input-port> is a MIDI input port number of the MIDI input device connected to the sampler channel given by <sampler-channel>.
If more than 1 MIDI inputs are currently connected to this sampler channel: Sending this command will switch the connection of the first (and only the first) MIDI input port currently being connected to this sampler channel, to another port of the same MIDI input device. Or in other words: the first MIDI input port currently connected to this sampler channel will be disconnected, and the requested other port of its MIDI input device will be connected to this sampler channel instead. This behavior is due to preserving full behavior backward compatibility.
Possible Answers:
Examples:
Deprecated:
The front-end can alter the MIDI channel a sampler channel should listen to by sending the following command:
Where <midi-input-chan> is the number of the new MIDI input channel (zero indexed!) where <sampler-channel> should listen to, or "ALL" to listen on all 16 MIDI channels.
Possible Answers:
Examples:
The front-end can alter the volume of a sampler channel by sending the following command:
Where <volume> is an optionally dotted positive number (a value smaller than 1.0 means attenuation, whereas a value greater than 1.0 means amplification) and <sampler-channel> defines the sampler channel where this volume factor should be set.
Possible Answers:
Examples:
The front-end can mute/unmute a specific sampler channel by sending the following command:
Where <sampler-channel> is the respective sampler channel number as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command and <mute> should be replaced either by "1" to mute the channel or "0" to unmute the channel.
Possible Answers:
Examples:
The front-end can solo/unsolo a specific sampler channel by sending the following command:
Where <sampler-channel> is the respective sampler channel number as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command and <solo> should be replaced either by "1" to solo the channel or "0" to unsolo the channel.
Possible Answers:
Examples:
The front-end can assign a MIDI instrument map to a specific sampler channel by sending the following command:
Where <sampler-channel> is the respective sampler channel number as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command and <map> can have the following possibilites:
Read chapter "MIDI Instrument Mapping" [MIDI Instrument Mapping] for details regarding MIDI instrument mapping.
Possible Answers:
Examples:
The front-end can create an additional effect send on a specific sampler channel by sending the following command:
Where <sampler-channel> is the respective sampler channel number as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command, that is the sampler channel on which the effect send should be created on, <midi-ctrl> is a number between 0..127 defining the MIDI controller which can alter the effect send level and <name> is an optional argument defining a name for the effect send entity. The name does not have to be unique, but MUST be encapsulated into apostrophes and supports escape sequences as described in chapter "Character Set and Escape Sequences [character_set]".
Note: there are two possible approaches to apply audio effects with FX sends: you can either use a) internal effects or b) external effects. By default, that is as initial routing, effect sends are automatically routed directly to the sampler channel's audio output device and the effect send's audio channels are by default automatically routed to the last audio channels of that audio output device (for the purpose of applying effects externally that is, e.g. by using another application), that way you can i.e. first increase the amount of audio channels on the audio output device for having dedicated effect send output channels and when "CREATE FX_SEND" is called, those channels will automatically be picked. You can alter the destination channels however with "SET FX_SEND AUDIO_OUTPUT_CHANNEL" [SET FX_SEND AUDIO_OUTPUT_CHANNEL]. If your intention is rather to use internal effects instead of external effects, then you first need to load those internal effects [effects] and then assign the FX sends to the desired internal effect by sending "SET FX_SEND EFFECT" [SET FX_SEND EFFECT].
Note: Create effect sends on a sampler channel only when needed, because having effect sends on a sampler channel will decrease runtime performance, because for implementing channel effect sends, separate (sampler channel local) audio buffers are needed to render and mix the voices and route the audio signal afterwards to the master outputs and effect send outputs (along with their respective effect send levels). A sampler channel without effect sends however can mix its voices directly into the audio output devices's audio buffers and is thus faster.
Possible Answers:
Examples:
The front-end can remove an existing effect send on a specific sampler channel by sending the following command:
Where <sampler-channel> is the respective sampler channel number as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command, that is the sampler channel from which the effect send should be removed from and <fx-send-id> is the respective effect send number as returned by the "CREATE FX_SEND" [CREATE FX_SEND] or "LIST FX_SENDS" [LIST FX_SENDS] command.
Possible Answers:
Example:
The front-end can ask for the amount of effect sends on a specific sampler channel by sending the following command:
Where <sampler-channel> is the respective sampler channel number as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command.
Possible Answers:
Example:
The front-end can ask for a list of effect sends on a specific sampler channel by sending the following command:
Where <sampler-channel> is the respective sampler channel number as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command.
Possible Answers:
Examples:
The front-end can ask for the current settings of an effect send entity by sending the following command:
Where <sampler-channel> is the sampler channel number as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command and <fx-send-id> reflects the numerical ID of the effect send entity as returned by the "CREATE FX_SEND" [CREATE FX_SEND] or "LIST FX_SENDS" [LIST FX_SENDS] command.
Possible Answers:
The mentioned fields above don't have to be in particular order.
Example:
The front-end can alter the current name of an effect send entity by sending the following command:
Where <sampler-chan> is the sampler channel number as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command, <fx-send-id> reflects the numerical ID of the effect send entity as returned by the "CREATE FX_SEND" [CREATE FX_SEND] or "LIST FX_SENDS" [LIST FX_SENDS] command and <name> is the new name of the effect send entity, which does not have to be unique (name MUST be encapsulated into apostrophes and supports escape sequences as described in chapter "Character Set and Escape Sequences [character_set]").
Possible Answers:
Example:
The front-end can alter the destination of an effect send's audio channel on a specific sampler channel by sending the following command:
Where <sampler-chan> is the sampler channel number as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command, <fx-send-id> reflects the numerical ID of the effect send entity as returned by the "CREATE FX_SEND" [CREATE FX_SEND] or "LIST FX_SENDS" [LIST FX_SENDS] command, <audio-src> is the numerical ID of the effect send's audio channel which should be rerouted and <audio-dst> is the numerical ID of either a) the audio output channel of the sampler channel's audio output device (i.e. if external effect shall be applied) or b) of the audio input channel of an internal effect assigned to the FX send where <audio-src> should be routed to.
Note that effect sends can only route audio to the same audio output device as assigned to the effect send's sampler channel. Also note that an effect send entity does always have exactly as much audio channels as its sampler channel. So if the sampler channel is stereo, the effect send does have two audio channels as well. Also keep in mind that the amount of audio channels on a sampler channel might be dependant not only to the deployed sampler engine on the sampler channel, but also dependant to the instrument currently loaded. However you can (effectively) turn an i.e. stereo effect send into a mono one by simply altering its audio routing appropriately.
Possible Answers:
Example:
The front-end can (re-)assign an internal destination effect to an effect send by sending the following command:
Where <sampler-chan> is the sampler channel number as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command, <fx-send-id> reflects the numerical ID of the effect send entity as returned by the "CREATE FX_SEND" [CREATE FX_SEND] or "LIST FX_SENDS" [LIST FX_SENDS] command, <effect-chain> by the numerical ID of the destination effect chain as returned by the "ADD SEND_EFFECT_CHAIN" [ADD SEND_EFFECT_CHAIN] or "LIST SEND_EFFECT_CHAINS" [LIST SEND_EFFECT_CHAINS] command and <chain-pos> reflects the exact effect chain position in the effect chain which hosts the actual destination effect.
Note: This command MUST NOT be used if you want to apply audio effects externally! By default FX sends are routed directly to the audio output device for that purpose. You can also revert this command later on by sending "REMOVE FX_SEND EFFECT" [REMOVE FX_SEND EFFECT], which will cause the FX send to be routed directly to the sampler channel's audio output device instead (i.e. for using external effects instead of internal effects).
Possible Answers:
Example:
The front-end can (re-)assign a destination effect to an effect send by sending the following command:
Where <sampler-chan> is the sampler channel number as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command, <fx-send-id> reflects the numerical ID of the effect send entity as returned by the "CREATE FX_SEND" [CREATE FX_SEND] or "LIST FX_SENDS" [LIST FX_SENDS] command.
After the destination effect has been removed from the effect send, the audio signal of the effect send will be routed directly to the audio output device, according to the audio channel routing setting of the effect send.
Possible Answers:
Example:
The front-end can alter the MIDI controller of an effect send entity by sending the following command:
Where <sampler-chan> is the sampler channel number as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command, <fx-send-id> reflects the numerical ID of the effect send entity as returned by the "CREATE FX_SEND" [CREATE FX_SEND] or "LIST FX_SENDS" [LIST FX_SENDS] command and <midi-ctrl> reflects the MIDI controller which shall be able to modify the effect send's send level.
Possible Answers:
Example:
The front-end can alter the current send level of an effect send entity by sending the following command:
Where <sampler-chan> is the sampler channel number as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command, <fx-send-id> reflects the numerical ID of the effect send entity as returned by the "CREATE FX_SEND" [CREATE FX_SEND] or "LIST FX_SENDS" [LIST FX_SENDS] command and <volume> is an optionally dotted positive number (a value smaller than 1.0 means attenuation, whereas a value greater than 1.0 means amplification) reflecting the new send level.
Possible Answers:
Example:
The front-end can send MIDI events to a specific sampler channel by sending the following command:
Where <sampler-chan> is the sampler channel number as returned by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command, <arg1> and <arg2> arguments depend on the <midi-msg> argument, which specifies the MIDI message type. Currently, the following MIDI messages are supported:
CAUTION: This command is provided for implementations of virtual MIDI keyboards and no realtime guarantee whatsoever will be made!
Possible Answers:
Example:
The front-end can reset a particular sampler channel by sending the following command:
Where <sampler-channel> defines the sampler channel to be reset. This will cause the engine on that sampler channel, its voices and eventually disk streams and all control and status variables to be reset.
Possible Answers:
Examples:
The following commands are used to control the connection to LinuxSampler.
The front-end can register itself to the LinuxSampler application to be informed about noteworthy events by sending this command:
where <event-id> will be replaced by the respective event that client wants to subscribe to.
Possible Answers:
Examples:
The front-end can unregister itself if it doesn't want to receive event messages anymore by sending the following command:
Where <event-id> will be replaced by the respective event that client doesn't want to receive anymore.
Possible Answers:
Examples:
To enable or disable back sending of commands to the client the following command can be used:
Where <value> should be replaced either by "1" to enable echo mode or "0" to disable echo mode. When echo mode is enabled, all commands send to LinuxSampler will be immediately send back and after this echo the actual response to the command will be returned. Echo mode will only be altered for the client connection that issued the "SET ECHO" command, not globally for all client connections.
Possible Answers:
Examples:
The client can close its network connection to LinuxSampler by sending the following command:
This is probably more interesting for manual telnet connections to LinuxSampler than really useful for a front-end implementation.
The following commands have global impact on the sampler.
The front-end can ask for the current number of active voices on the sampler by sending the following command:
Possible Answers:
The front-end can ask for the maximum number of active voices by sending the following command:
Possible Answers:
The front-end can ask for the current number of active disk streams on the sampler by sending the following command:
Possible Answers:
The front-end can reset the whole sampler by sending the following command:
Possible Answers:
Examples:
The client can ask for general information about the LinuxSampler instance by sending the following command:
Possible Answers:
The mentioned fields above don't have to be in particular order. Other fields might be added in future.
Example:
The client can ask for the current global sampler-wide volume attenuation by sending the following command:
Possible Answers:
Note: it is up to the respective sampler engine whether to obey that global volume parameter or not, but in general all engines SHOULD use this parameter.
The client can alter the current global sampler-wide volume attenuation by sending the following command:
Where <volume> should be replaced by the optional dotted floating point value, reflecting the new global volume parameter. This value might usually be in the range between 0.0 and 1.0, that is for attenuating the overall volume.
Possible Answers:
The client can ask for the current global sampler-wide limit for maximum voices by sending the following command:
Possible Answers:
The voice limit setting defines how many voices should maximum be processed by the sampler at the same time. If the user triggers new notes which would exceed that voice limit, the sampler engine will react by stealing old voices for those newly triggered notes. Note that the amount of voices triggered by a new note can be larger than one and is dependent to the respective instrument and probably further criterias.
The client can alter the current global sampler-wide limit for maximum voices by sending the following command:
Where <max-voices> should be replaced by the integer value, reflecting the new global amount limit of maximum voices. This value has to be larger than 0.
Possible Answers:
Note: the given value will be passed to all sampler engine instances. The total amount of maximum voices on the running system might thus be as big as the given value multiplied by the current amount of engine instances.
Caution: when adjusting the voice limit, you SHOULD also adjust the disk stream limit respectively and vice versa.
The client can ask for the current global sampler-wide limit for maximum disk streams by sending the following command:
Possible Answers:
The disk stream limit setting defines how many disk streams should maximum be processed by a sampler engine at the same time. The higher this value, the more memory (RAM) will be occupied, since every disk streams allocates a certain buffer size for being able to perform its streaming operations.
The client can alter the current global sampler-wide limit for maximum disk streams by sending the following command:
Where <max-streams> should be replaced by the integer value, reflecting the new global amount limit of maximum disk streams. This value has to be positive.
Possible Answers:
Note: the given value will be passed to all sampler engine instances. The total amount of maximum disk streams on the running system might thus be as big as the given value multiplied by the current amount of engine instances.
Caution: when adjusting the disk stream limit, you SHOULD also adjust the voice limit respectively and vice versa.
The MIDI protocol provides a way to switch between instruments by sending so called MIDI bank select and MIDI program change messages which are essentially just numbers. The following commands allow to actually map arbitrary MIDI bank select / program change numbers with real instruments.
The sampler allows to manage an arbitrary amount of MIDI instrument maps which define which instrument to load on which MIDI program change message.
By default, that is when the sampler is launched, there is no map, thus the sampler will simply ignore all program change messages. The front-end has to explicitly create at least one map, add entries to the map and tell the respective sampler channel(s) which MIDI instrument map to use, so the sampler knows how to react on a given program change message on the respective sampler channel, that is by switching to the respectively defined engine type and loading the respective instrument. See command "SET CHANNEL MIDI_INSTRUMENT_MAP" [SET CHANNEL MIDI_INSTRUMENT_MAP] for how to assign a MIDI instrument map to a sampler channel.
Also note per MIDI specification a bank select message does not cause to switch to another instrument. Instead when receiving a bank select message the bank value will be stored and a subsequent program change message (which may occur at any time) will finally cause the sampler to switch to the respective instrument as reflected by the current MIDI instrument map.
The front-end can add a new MIDI instrument map by sending the following command:
Where <name> is an optional argument allowing to assign a custom name to the new map. MIDI instrument Map names do not have to be unique, but MUST be encapsulated into apostrophes and support escape sequences as described in chapter "Character Set and Escape Sequences [character_set]".
Possible Answers:
Examples:
The front-end can delete a particular MIDI instrument map by sending the following command:
Where <map> reflects the unique ID of the map to delete as returned by the "LIST MIDI_INSTRUMENT_MAPS" [LIST MIDI_INSTRUMENT_MAPS] command.
The front-end can delete all MIDI instrument maps by sending the following command:
Possible Answers:
Examples:
The front-end can retrieve the current amount of MIDI instrument maps by sending the following command:
Possible Answers:
Example:
The number of MIDI instrument maps can change on runtime. To get the current list of MIDI instrument maps, the front-end can send the following command:
Possible Answers:
Example:
The front-end can ask for the current settings of a MIDI instrument map by sending the following command:
Where <map> is the numerical ID of the map the front-end is interested in as returned by the "LIST MIDI_INSTRUMENT_MAPS" [LIST MIDI_INSTRUMENT_MAPS] command.
Possible Answers:
The mentioned fields above don't have to be in particular order.
Example:
The front-end can alter the custom name of a MIDI instrument map by sending the following command:
Where <map> is the numerical ID of the map and <name> the new custom name of the map, which does not have to be unique (name MUST be encapsulated into apostrophes and supports escape sequences as described in chapter "Character Set and Escape Sequences [character_set]").
Possible Answers:
Example:
The front-end can create a new or replace an existing entry in a sampler's MIDI instrument map by sending the following command:
Where <map> is the numeric ID of the map to alter, <midi_bank> is an integer value between 0..16383 reflecting the MIDI bank select index, <midi_prog> an integer value between 0..127 reflecting the MIDI program change index, <engine_name> a sampler engine name as returned by the "LIST AVAILABLE_ENGINES" [LIST AVAILABLE_ENGINES] command (not encapsulated into apostrophes), <filename> the name of the instrument's file to be deployed (encapsulated into apostrophes, supporting escape sequences as described in chapter "Character Set and Escape Sequences [character_set]"), <instrument_index> the index (integer value) of the instrument within the given file, <volume_value> reflects the master volume of the instrument as optionally dotted number (where a value < 1.0 means attenuation and a value > 1.0 means amplification). This parameter easily allows to adjust the volume of all intruments within a custom instrument map without having to adjust their instrument files. The OPTIONAL <instr_load_mode> argument defines the life time of the instrument, that is when the instrument should be loaded, when freed and has exactly the following possibilities:
The <instr_load_mode> argument thus allows to define an appropriate strategy (low memory consumption vs. fast instrument switching) for each instrument individually. Note, the following restrictions apply to this argument: "ON_DEMAND_HOLD" and "PERSISTENT" have to be supported by the respective sampler engine (which is technically the case when the engine provides an InstrumentManager for its format). If this is not the case the argument will automatically fall back to the default value "ON_DEMAND". Also the load mode of one instrument may automatically change the laod mode of other instrument(s), i.e. because the instruments are part of the same file and the engine does not allow a way to manage load modes for them individually. Due to this, in case the frontend shows the load modes of entries, the frontend should retrieve the actual mode by i.e. sending "GET MIDI_INSTRUMENT INFO" [GET MIDI_INSTRUMENT INFO] command(s). Finally the OPTIONAL <name> argument allows to set a custom name (encapsulated into apostrophes, supporting escape sequences as described in chapter "Character Set and Escape Sequences [character_set]") for the mapping entry, useful for frontends for displaying an appropriate name for mapped instruments (using "GET MIDI_INSTRUMENT INFO" [GET MIDI_INSTRUMENT INFO]).
By default, "MAP MIDI_INSTRUMENT" commands block until the mapping is completely established in the sampler. The OPTIONAL "NON_MODAL" argument however causes the respective "MAP MIDI_INSTRUMENT" command to return immediately, that is to let the sampler establish the mapping in the background. So this argument might be especially useful for mappings with a "PERSISTENT" type, because these have to load the respective instruments immediately and might thus block for a very long time. It is recommended however to use the OPTIONAL "NON_MODAL" argument only if really necessary, because it has the following drawbacks: as "NON_MODAL" instructions return immediately, they may not necessarily return an error i.e. when the given instrument file turns out to be corrupt, beside that subsequent commands in a LSCP instruction sequence might fail, because mandatory mappings are not yet completed.
Possible Answers:
Examples:
The front-end can query the amount of currently existing entries in a MIDI instrument map by sending the following command:
The front-end can query the amount of currently existing entries in all MIDI instrument maps by sending the following command:
Possible Answers:
Example:
The front-end can query a list of all currently existing entries in a certain MIDI instrument map by sending the following command:
Where <map> is the numeric ID of the MIDI instrument map.
The front-end can query a list of all currently existing entries of all MIDI instrument maps by sending the following command:
Possible Answers:
Example:
The front-end can delete an entry from a MIDI instrument map by sending the following command:
Where <map> is the numeric ID of the MIDI instrument map, <midi_bank> is an integer value between 0..16383 reflecting the MIDI bank value and <midi_prog> an integer value between 0..127 reflecting the MIDI program value of the map's entrie's key index triple.
Possible Answers:
Example:
The front-end can retrieve the current settings of a certain instrument map entry by sending the following command:
Where <map> is the numeric ID of the MIDI instrument map, <midi_bank> is an integer value between 0..16383 reflecting the MIDI bank value, <midi_bank> and <midi_prog> an integer value between 0..127 reflecting the MIDI program value of the map's entrie's key index triple.
Possible Answers:
Example:
The front-end can clear a whole MIDI instrument map, that is delete all its entries by sending the following command:
Where <map> is the numeric ID of the map to clear.
The front-end can clear all MIDI instrument maps, that is delete all entries of all maps by sending the following command:
The command "CLEAR MIDI_INSTRUMENTS ALL" does not delete the maps, only their entries, thus the map's settings like custom name will be preservevd.
Possible Answers:
Examples:
The following commands describe how to use and manage the instruments database.
Notice:
The front-end can add a new instrument directory to the instruments database by sending the following command:
Where <dir> is the absolute path name of the directory to be created (encapsulated into apostrophes).
Possible Answers:
Examples:
The front-end can delete a particular instrument directory from the instruments database by sending the following command:
Where <dir> is the absolute path name of the directory to delete. The optional FORCE argument can be used to force the deletion of a non-empty directory and all its content.
Possible Answers:
Examples:
The front-end can retrieve the current amount of directories in a specific directory by sending the following command:
Where <dir> should be replaced by the absolute path name of the directory. If RECURSIVE is specified, the number of all directories, including those located in subdirectories of the specified directory, will be returned.
Possible Answers:
Example:
The front-end can retrieve the current list of directories in specific directory by sending the following command:
Where <dir> should be replaced by the absolute path name of the directory. If RECURSIVE is specified, the absolute path names of all directories, including those located in subdirectories of the specified directory, will be returned.
Possible Answers:
Example:
The front-end can ask for the current settings of an instrument directory by sending the following command:
Where <dir> should be replaced by the absolute path name of the directory the front-end is interested in.
Possible Answers:
The mentioned fields above don't have to be in particular order.
Example:
The front-end can alter the name of a specific instrument directory by sending the following command:
Where <dir> is the absolute path name of the directory and <name> is the new name for that directory.
Possible Answers:
Example:
The front-end can move a specific instrument directory by sending the following command:
Where <dir> is the absolute path name of the directory to move and <dst> is the location where the directory will be moved to.
Possible Answers:
Example:
The front-end can copy a specific instrument directory by sending the following command:
Where <dir> is the absolute path name of the directory to copy and <dst> is the location where the directory will be copied to.
Possible Answers:
Example:
The front-end can alter the description of a specific instrument directory by sending the following command:
Where <dir> is the absolute path name of the directory and <desc> is the new description for the directory (encapsulated into apostrophes, supporting escape sequences as described in chapter "Character Set and Escape Sequences [character_set]").
Possible Answers:
Example:
The front-end can search for directories in specific directory by sending the following command:
Where <dir> should be replaced by the absolute path name of the directory to search in. If NON_RECURSIVE is specified, the directories located in subdirectories of the specified directory will not be searched. <criteria-list> is a list of search criterias in form of "key1=val1 key2=val2 ...". The following criterias are allowed:
Where <search-string> is either a regular expression, or a word list separated with spaces for OR search and with '+' for AND search.
Possible Answers:
Example:
The front-end can add one or more instruments to the instruments database by sending the following command:
Where <db_dir> is the absolute path name of a directory (encapsulated into apostrophes) in the instruments database in which only the new instruments (that are not already in the database) will be added, <file_path> is the absolute path name of a file or directory in the file system (encapsulated into apostrophes). In case an instrument file is supplied, only the instruments in the specified file will be added to the instruments database. If the optional <instr_index> (the index of the instrument within the given file) is supplied too, then only the specified instrument will be added. In case a directory is supplied, the instruments in that directory will be added. The OPTIONAL <mode> argument is only applied when a directory is provided as <file_path> and specifies how the scanning will be done and has exactly the following possibilities:
If FILE_AS_DIR argument is supplied, all instruments in an instrument file will be added to a separate directory in the instruments database, which name will be the name of the instrument file with the file extension stripped off.
The difference between regular and NON_MODAL versions of the command is that the regular command returns when the scanning is finished while NON_MODAL version returns immediately and a background process is launched. The GET DB_INSTRUMENTS_JOB INFO [GET DB_INSTRUMENTS_JOB INFO] command can be used to monitor the scanning progress.
Possible Answers:
Examples:
The front-end can remove a particular instrument from the instruments database by sending the following command:
Where <instr_path> is the absolute path name (in the instruments database) of the instrument to remove.
Possible Answers:
Examples:
The front-end can retrieve the current amount of instruments in a specific directory by sending the following command:
Where <dir> should be replaced by the absolute path name of the directory. If RECURSIVE is specified, the number of all instruments, including those located in subdirectories of the specified directory, will be returned.
Possible Answers:
Example:
The front-end can retrieve the current list of instruments in specific directory by sending the following command:
Where <dir> should be replaced by the absolute path name of the directory. If RECURSIVE is specified, the absolute path names of all instruments, including those located in subdirectories of the specified directory, will be returned.
Possible Answers:
Example:
The front-end can ask for the current settings of an instrument by sending the following command:
Where <instr_path> should be replaced by the absolute path name of the instrument the front-end is interested in.
Possible Answers:
The mentioned fields above don't have to be in particular order.
Example:
The front-end can alter the name of a specific instrument by sending the following command:
Where <instr> is the absolute path name of the instrument and <name> is the new name for that instrument.
Possible Answers:
Example:
The front-end can move a specific instrument to another directory by sending the following command:
Where <instr> is the absolute path name of the instrument to move and <dst> is the directory where the instrument will be moved to.
Possible Answers:
Example:
The front-end can copy a specific instrument to another directory by sending the following command:
Where <instr> is the absolute path name of the instrument to copy and <dst> is the directory where the instrument will be copied to.
Possible Answers:
Example:
The front-end can alter the description of a specific instrument by sending the following command:
Where <instr> is the absolute path name of the instrument and <desc> is the new description for the instrument (encapsulated into apostrophes, supporting escape sequences as described in chapter "Character Set and Escape Sequences [character_set]").
Possible Answers:
Example:
The front-end can search for instruments in specific directory by sending the following command:
Where <dir> should be replaced by the absolute path name of the directory to search in. If NON_RECURSIVE is specified, the directories located in subdirectories of the specified directory will not be searched. <criteria-list> is a list of search criterias in form of "key1=val1 key2=val2 ...". The following criterias are allowed:
Where <search-string> is either a regular expression, or a word list separated with spaces for OR search and with '+' for AND search.
Possible Answers:
Example:
The front-end can ask for the current status of a particular database instruments job by sending the following command:
Where <job-id> should be replaced by the numerical ID of the job the front-end is interested in.
Possible Answers:
The mentioned fields above don't have to be in particular order.
Example:
The front-end can remove all instruments and directories and re-create the instruments database structure (e.g., in case of a database corruption) by sending the following command:
Possible Answers:
The front-end can retrieve the list of all instrument files in the instruments database that don't exist in the filesystem by sending the following command:
Possible Answers:
Example:
The front-end can substitute all occurrences of an instrument file in the instruments database with a new one by sending the following command:
Where <old_path> is the absolute path name of the instrument file to substitute with <new_path>.
Possible Answers:
Example:
The sampler allows to edit instruments while playing with the sampler by spawning an external (3rd party) instrument editor application for a given instrument. The 3rd party instrument editor applications have to place a respective plugin DLL file into the sampler's plugins directory. The sampler will automatically try to load all plugin DLLs in that directory on startup and only on startup!
At the moment there is only one command for this feature set, but this will most probably change in future.
The front-end can request to open an appropriate instrument editor application by sending the following command:
Where <sampler-channel> should be replaced by the number of the sampler channel as given by the "ADD CHANNEL" [ADD CHANNEL] or "LIST CHANNELS" [LIST CHANNELS] command.
The sampler will try to ask all registered instrument editors (or to be more specific: their sampler plugins) whether they are capable to handle the instrument on the given sampler channel. The sampler will simply use the first instrument editor application which replied with a positive answer and spawn that instrument editor application within the sampler's process and provide that application access to the instrument's data structures, so both applications can share and access the same instruments data at the same time, thus allowing to immediately hear changes with the sampler made by the instrument editor.
Note: consequently instrument editors are always spawned locally on the same machine where the sampler is running on!
Possible Answers:
Examples:
You can query detailed information about files located at the same system where the sampler instance is running on. Using this command set allows to retrieve file information even remotely from another machine.
The front-end can retrieve the amount of instruments within a given instrument file by sending the following command:
Where <filename> is the name of the instrument file (encapsulated into apostrophes, supporting escape sequences as described in chapter "Character Set and Escape Sequences [character_set]").
The sampler will try to ask all sampler engines, whether they support the given file and ask the first engine with a positive answer for the amount of instruments.
Possible Answers:
Examples:
The front-end can retrieve a list of all instruments within a given instrument file by sending the following command:
Where <filename> is the name of the instrument file (encapsulated into apostrophes, supporting escape sequences as described in chapter "Character Set and Escape Sequences [character_set]").
The sampler will try to ask all sampler engines, whether they support the given file and ask the first engine with a positive answer for a list of IDs for the instruments in the given file.
Possible Answers:
Examples:
The front-end can retrieve detailed information about a specific instrument within a given instrument file by sending the following command:
Where <filename> is the name of the instrument file (encapsulated into apostrophes, supporting escape sequences as described in chapter "Character Set and Escape Sequences [character_set]") and <instr-id> is the numeric instrument ID as returned by the "LIST FILE INSTRUMENTS" [LIST FILE INSTRUMENTS] command.
The sampler will try to ask all sampler engines, whether they support the given file and ask the first engine with a positive answer for information about the specific instrument in the given file.
Possible Answers:
The mentioned fields above don't have to be in particular order.
Example:
There are two possible approaches to apply audio effects (e.g. reverb, delay, compression). You can either a) load and apply internal effects or you can b) route effect sends directly to dedicated output channels of your audio device and apply effects externally (e.g. by routing those dedicated output channels to another application).
This chapter describes how to load and manage internal effects. If your intention is rather to apply effects externally, then you can omit this chapter. For applying effects externally, you just need to create FX sends [CREATE FX_SEND] on the respective sampler channel(s) and adjust their destination audio channels [SET FX_SEND AUDIO_OUTPUT_CHANNEL] appropriately, because by default FX sends are automatically routed directly to the audio output device.
The sampler usually provides a set of internal audio effects. The exact set of effects depends on the availability of third party effect plugins installed on the system where the sampler runs on (e.g. LADSPA plugins).
At the moment only "send effects" are supported. Support for "insert effects" and "master effects" is planned to be added at a later point.
The following commands allow to retrieve the set of internal effects available to the sampler, detailed information about those effects and to create and destroy instances of such effects. After an instance of an effect is created, the effect instance can be inserted into the audio signal path of the sampler, e.g. as send effect.
The sampler allows to create an arbitrary amount of so called send effect chains. Each effect chain can host an arbitrary amount of effect instances. The output of the first effect instance in an effect chain is fed to the input of the second effect instance of the chain and so on. So effects in one chain are processed sequentially. Send effect chains however are processed in parallel to other send effect chains. Audio signals of sampler channels are fed to send effects by creating FX sends to the respective sampler channel and assigning a destination send effect to that FX by using the "SET FX_SEND EFFECT" [SET FX_SEND EFFECT] command. The latter allows to route the FX send to the beginning of a send effect chain, as well as directly to any other position of the send effect chain.
The front-end can retrieve the amount of internal effects, available to the sampler by sending the following command:
Possible Answers:
Examples:
The set of available internal effects can change at runtime. The front-end can retrieve the list of internal effects, available to the sampler by sending the following command:
Possible Answers:
Example:
The front-end can ask for general information about an effect by sending the following command:
Where <effect-index> is the numerical ID of an effect as returned by the "LIST AVAILABLE_EFFECTS" [LIST AVAILABLE_EFFECTS] command.
Possible Answers:
The mentioned fields above don't have to be in particular order.
Example:
The front-end can spawn an instance of the desired effect by sending the following command:
Where <effect-system> is the "SYSTEM" field, <module> the "MODULE" field and <effect-name> the "NAME" field as returned by the "GET EFFECT INFO" [GET EFFECT INFO] command. The filename of argument <module> and the character string of argument <effect-name> may contain escape sequences [character_set].
The sampler will try to load the requested effect and to create an instance of it. To allow loading the same effect on a different machine, probably even running a completely different operating system (e.g. Linux vs. Windows), the sampler tries to match <module> "softly". That means it first tries to find an effect that exactly matches the given <module> argument. If there is no exact match, the sampler will try to lower the restrictions on matching the <module> argument more and more, e.g. by ignoring upper / lower case differences and by ignoring the path of the DLL filename and file extension. If there is still no match at the end, the sampler will try to ignore the <module> argument completely and as a last resort search for an effect that only matches the given <effect-system> and <effect-name> arguments.
Possible Answers:
Examples:
The front-end can spawn an instance of the desired effect by sending the following command:
Where <effect-index> is the numerical ID of the effect as returned by the "LIST AVAILABLE_EFFECTS" [LIST AVAILABLE_EFFECTS] command.
The sampler will try to load the requested effect and to create an instance of it.
Note: Since the numerical ID of a certain effect can change at any time, you should not use this command in LSCP files to restore a certain effect at a later time! To store a sampler session including all its effects, use the portable text-based version of "CREATE EFFECT_INSTANCE" [CREATE EFFECT_INSTANCE] instead! This allows to restore a sampler session with all its effects also on other machines, possibly even running a completely different operating system (e.g. Linux vs. Windows), with different plugin directories or plugin DLL names.
Possible Answers:
Examples:
The front-end can destroy an unusued effect instance and thus freeing it from memory by sending the following command:
Where <effect-instance> is the numerical ID of the effect instance as returned by the "CREATE EFFECT_INSTANCE" [CREATE EFFECT_INSTANCE] or "LIST EFFECT_INSTANCES" [LIST EFFECT_INSTANCES] command.
The effect instance can only be destroyed if it's not used in any part of the sampler's audio signal path anymore. If the effect instance is still in use somewhere, trying to destroy the effect instance will result in an error message.
Possible Answers:
Examples:
The front-end can retrieve the current amount of effect instances by sending the following command:
Possible Answers:
Examples:
The front-end can retrieve the current list of effect instances by sending the following command:
Possible Answers:
Example:
The front-end can ask for the current information about a particular effect instance by sending the following command:
Where <effect-instance> is the numerical ID of an effect instance as returned by the "CREATE EFFECT_INSTANCE" [CREATE EFFECT_INSTANCE] or "LIST EFFECT_INSTANCES" [LIST EFFECT_INSTANCES] command.
Possible Answers:
The mentioned fields above don't have to be in particular order.
Example:
Effects typically provide a certain set of effect parameters which can be altered by the user in realtime (e.g. depth of a reverb effect, duration of a delay effect, dry / wet signal ratio). Those controllable effect parameters are called "input controls". The front-end can ask for the current information of an effect instance's input control by sending the following command:
Where <effect-instance> is the numerical ID of an effect instance as returned by the "CREATE EFFECT_INSTANCE" [CREATE EFFECT_INSTANCE] or "LIST EFFECT_INSTANCES" [LIST EFFECT_INSTANCES] command and <input-control> is the index of the input control within the numerical bounds as returned by the "INPUT_CONTROLS" field of the "GET EFFECT_INSTANCE INFO" [GET EFFECT_INSTANCE INFO] command.
Possible Answers:
The mentioned fields above don't have to be in particular order.
Example:
The front-end can alter the current value of an effect parameter by sending the following command:
Where <effect-instance> is the numerical ID of the effect instance as returned by the "CREATE EFFECT_INSTANCE" [CREATE EFFECT_INSTANCE] or "LIST EFFECT_INSTANCES" [LIST EFFECT_INSTANCES] command, <input-control> is the index of the input control within the numerical bounds as returned by the "INPUT_CONTROLS" field of the "GET EFFECT_INSTANCE INFO" [GET EFFECT_INSTANCE INFO] command and <value> is the new (optional dotted) floating point value for this effect parameter.
Possible Answers:
Examples:
The front-end can retrieve the current amount of send effect chains of an audio output device by sending the following command:
Where <audio-device> should be replaced by the numerical ID of the audio output device as given by the "CREATE AUDIO_OUTPUT_DEVICE" [CREATE AUDIO_OUTPUT_DEVICE] or "LIST AUDIO_OUTPUT_DEVICES" [LIST AUDIO_OUTPUT_DEVICES] command.
Possible Answers:
Examples:
The front-end can retrieve the current list of send effect chains of an audio output device by sending the following command:
Where <audio-device> should be replaced by the numerical ID of the audio output device as given by the "CREATE AUDIO_OUTPUT_DEVICE" [CREATE AUDIO_OUTPUT_DEVICE] or "LIST AUDIO_OUTPUT_DEVICES" [LIST AUDIO_OUTPUT_DEVICES] command.
Possible Answers:
Examples:
The front-end can add a send effect chain by sending the following command:
Where <audio-device> should be replaced by the numerical ID of the audio output device as given by the "CREATE AUDIO_OUTPUT_DEVICE" [CREATE AUDIO_OUTPUT_DEVICE] or "LIST AUDIO_OUTPUT_DEVICES" [LIST AUDIO_OUTPUT_DEVICES] command.
Possible Answers:
Examples:
The front-end can remove a send effect chain by sending the following command:
Where <audio-device> should be replaced by the numerical ID of the audio output device as given by the "CREATE AUDIO_OUTPUT_DEVICE" [CREATE AUDIO_OUTPUT_DEVICE] or "LIST AUDIO_OUTPUT_DEVICES" [LIST AUDIO_OUTPUT_DEVICES] command and <effect-chain> by the numerical ID as returned by the "ADD SEND_EFFECT_CHAIN" [ADD SEND_EFFECT_CHAIN] or "LIST SEND_EFFECT_CHAINS" [LIST SEND_EFFECT_CHAINS] command.
Possible Answers:
Examples:
The front-end can ask for information of a send effect chain by sending the following command:
Where <audio-device> should be replaced by the numerical ID of the audio output device as given by the "CREATE AUDIO_OUTPUT_DEVICE" [CREATE AUDIO_OUTPUT_DEVICE] or "LIST AUDIO_OUTPUT_DEVICES" [LIST AUDIO_OUTPUT_DEVICES] command and <effect-chain> by the numerical ID as returned by the "ADD SEND_EFFECT_CHAIN" [ADD SEND_EFFECT_CHAIN] or "LIST SEND_EFFECT_CHAINS" [LIST SEND_EFFECT_CHAINS] command.
Possible Answers:
The mentioned fields above don't have to be in particular order.
Example:
The front-end can add an unused effect instance to the end of a send effect chain by sending the following command:
Where <audio-device> should be replaced by the numerical ID of the audio output device as given by the "CREATE AUDIO_OUTPUT_DEVICE" [CREATE AUDIO_OUTPUT_DEVICE] or "LIST AUDIO_OUTPUT_DEVICES" [LIST AUDIO_OUTPUT_DEVICES] command and <effect-chain> by the numerical ID as returned by the "ADD SEND_EFFECT_CHAIN" [ADD SEND_EFFECT_CHAIN] or "LIST SEND_EFFECT_CHAINS" [LIST SEND_EFFECT_CHAINS] command and <effect-instance> as returned by the "CREATE EFFECT_INSTANCE" [CREATE EFFECT_INSTANCE] or "LIST EFFECT_INSTANCES" [LIST EFFECT_INSTANCES] command.
Only unused effect instances can be added to the effect chain. Trying to add an effect instance which is already in use somewhere in the audio signal path of the sampler will result in an error.
Possible Answers:
Examples:
The front-end can add an unused effect instance to a certain position of a send effect chain by sending the following command:
Where <audio-device> should be replaced by the numerical ID of the audio output device as given by the "CREATE AUDIO_OUTPUT_DEVICE" [CREATE AUDIO_OUTPUT_DEVICE] or "LIST AUDIO_OUTPUT_DEVICES" [LIST AUDIO_OUTPUT_DEVICES] command, <effect-chain> by the numerical ID as returned by the "ADD SEND_EFFECT_CHAIN" [ADD SEND_EFFECT_CHAIN] or "LIST SEND_EFFECT_CHAINS" [LIST SEND_EFFECT_CHAINS] command, <effect-instance> as returned by the "CREATE EFFECT_INSTANCE" [CREATE EFFECT_INSTANCE] or "LIST EFFECT_INSTANCES" [LIST EFFECT_INSTANCES] command and <chain-pos> the exact position of the effect chain where the supplied effect shall be inserted to.
Only unused effect instances can be added to the effect chain. Trying to add an effect instance which is already in use somewhere in the audio signal path of the sampler will result in an error.
Possible Answers:
Examples:
The front-end can remove an effect instance from a certain position of a send effect chain by sending the following command:
Where <audio-device> should be replaced by the numerical ID of the audio output device as given by the "CREATE AUDIO_OUTPUT_DEVICE" [CREATE AUDIO_OUTPUT_DEVICE] or "LIST AUDIO_OUTPUT_DEVICES" [LIST AUDIO_OUTPUT_DEVICES] command, <effect-chain> by the numerical ID as returned by the "ADD SEND_EFFECT_CHAIN" [ADD SEND_EFFECT_CHAIN] or "LIST SEND_EFFECT_CHAINS" [LIST SEND_EFFECT_CHAINS] command and <chain-pos> the exact position of the effect instance to be removed from the effect chain.
Possible Answers:
Examples:
The grammar of the control protocol as descibed in Section 6 is defined below using Backus-Naur Form (BNF as described in [RFC2234]) where applicable.
input =
line =
statement =
comment =
command =
add_instruction =
subscribe_event =
unsubscribe_event =
map_instruction =
unmap_instruction =
remove_instruction =
get_instruction =
set_instruction =
create_instruction =
reset_instruction =
clear_instruction =
find_instruction =
move_instruction =
copy_instruction =
destroy_instruction =
load_instruction =
append_instruction =
insert_instruction =
set_chan_instruction =
edit_instruction =
format_instruction =
modal_arg =
key_val_list =
buffer_size_type =
list_instruction =
send_instruction =
load_instr_args =
load_engine_args =
instr_load_mode =
effect_instance =
device_index =
audio_channel_index =
audio_output_type_name =
midi_input_port_index =
midi_input_channel_index =
midi_input_type_name =
midi_map =
midi_bank =
midi_prog =
midi_ctrl =
volume_value =
control_value =
sampler_channel =
instrument_index =
fx_send_id =
engine_name =
filename =
db_path =
map_name =
entry_name =
fx_send_name =
effect_name =
effect_index =
effect_chain =
chain_pos =
input_control =
param_val_list =
param_val =
query_val_list =
query_val =
scan_mode =
effect_system =
module =
Older versions of this protocol up to and including v1.1 only supported the standard ASCII character set (ASCII code 0 - 127) [RFC20], all younger versions of this protocol however support the Extended ASCII character set (ASCII code 0 - 255). The same group of younger protocols also support escape sequences, but only for certain, explicitly declared parts of the protocol. The supported escape sequences are defined as follows:
| ASCII Character Sequence | Translated into (Name) |
|---|---|
| \n | new line |
| \r | carriage return |
| \f | form feed |
| \t | horizontal tab |
| \v | vertical tab |
| \' | apostrophe |
| \" | quotation mark |
| \\ | backslash |
| \OOO | three digit octal ASCII code of the character |
| \xHH | two digit hex ASCII code of the character |
Notice: due to the transition of certain parts of the protocol which now support escape sequences, a slight backward incompatibility to protocols version v1.1 and younger has been introduced. The only difference is that in parts of the protocol where escape characters are now supported, a backslash characters MUST be escaped as well (that is as double backslash), whereas in the old versions a single backslash was sufficient.
The following LSCP commands support escape sequences as part of their filename / path based arguments and / or may contain a filename / path with escape sequences in their response:
Note that the forward slash character ('/') has a special meaning in filename / path based arguments: it acts as separator of the nodes in the path, thus if a directory- or filename includes a forward slash (not intended as path node separator), you MUST escape that slash either with the respective hex escape sequence ("\x2f") or with the respective octal escape sequence ("\057").
Note for Windows: file path arguments in LSCP are expected to use forward slashes as directory node separator similar to Unix based operating systems. In contrast to Unix however a Windows typical drive character is expected to be prefixed to the path. That is an original Windows file path like "D:\Sounds\My.gig" would become in LSCP: "D:/Sounds/My.gig".
The following LSCP commands even support escape sequences as part of at least one of their text-based arguments (i.e. entity name, description) and / or may contain escape sequences in at least one of their text-based fields in their response:
Please note that these lists are manually maintained. If you find a command that also supports escape sequences we forgot to mention here, please report it!
This chapter will describe all currently defined events supported by LinuxSampler.
Client may want to be notified when the total number of audio output devices on the back-end changes by issuing the following command:
Server will start sending the following notification messages:
where <devices> will be replaced by the new number of audio output devices.
Client may want to be notified when changes were made to audio output devices on the back-end by issuing the following command:
Server will start sending the following notification messages:
where <device-id> will be replaced by the numerical ID of the audio output device, which settings has been changed. The front-end will have to send the respective command to actually get the audio output device info. Because these messages will be triggered by LSCP commands issued by other clients rather than real time events happening on the server, it is believed that an empty notification message is sufficient here.
Client may want to be notified when the total number of MIDI input devices on the back-end changes by issuing the following command:
Server will start sending the following notification messages:
where <devices> will be replaced by the new number of MIDI input devices.
Client may want to be notified when changes were made to MIDI input devices on the back-end by issuing the following command:
Server will start sending the following notification messages:
where <device-id> will be replaced by the numerical ID of the MIDI input device, which settings has been changed. The front-end will have to send the respective command to actually get the MIDI input device info. Because these messages will be triggered by LSCP commands issued by other clients rather than real time events happening on the server, it is believed that an empty notification message is sufficient here.
Client may want to be notified when the total number of channels on the back-end changes by issuing the following command:
Server will start sending the following notification messages:
where <channels> will be replaced by the new number of sampler channels.
Client may want to be notified when MIDI data arrive on sampler channels on back-end side, by issuing the following command:
Server will start sending one of the the following notification messages:
where <channel-id> will be replaced by the ID of the sampler channel where the MIDI data arrived. <note> and <velocity> are integer values in the range between 0 .. 127, reflecting the analog meaning of the MIDI specification.
CAUTION: no guarantee whatsoever will be made that MIDI events are actually all delivered by this mechanism! With other words: events could be lost at any time! This restriction was made to keep the RT-safeness of the backend's MIDI and audio thread unaffected by this feature.
Client may want to be notified when MIDI data arrive on MIDI input devices by issuing the following command:
Server will start sending one of the the following notification messages:
where <device-id> <port-id> will be replaced by the IDs of the respective MIDI input device and the device's MIDI port where the MIDI data arrived. <note> and <velocity> are integer values in the range between 0 .. 127, reflecting the analog meaning of the MIDI specification.
CAUTION: no guarantee whatsoever will be made that MIDI events are actually all delivered by this mechanism! With other words: events could be lost at any time! This restriction was made to keep the RT-safeness of the backend's MIDI and audio thread unaffected by this feature.
Client may want to be notified when the number of voices on the back-end changes by issuing the following command:
Server will start sending the following notification messages:
where <sampler-channel> will be replaced by the sampler channel the voice count change occurred and <voices> by the new number of active voices on that channel.
Client may want to be notified when the number of streams on the back-end changes by issuing the following command: SUBSCRIBE STREAM_COUNT
Server will start sending the following notification messages:
where <sampler-channel> will be replaced by the sampler channel the stream count change occurred and <streams> by the new number of active disk streams on that channel.
Client may want to be notified when the buffer fill state of a disk stream on the back-end changes by issuing the following command:
Server will start sending the following notification messages:
where <sampler-channel> will be replaced by the sampler channel the buffer fill state change occurred on and <fill-data> will be replaced by the buffer fill data for this channel as described in Section 6.4.13 as if the "GET CHANNEL BUFFER_FILL PERCENTAGE" [GET CHANNEL BUFFER_FILL] command was issued on this channel.
Client may want to be notified when changes were made to sampler channels on the back-end by issuing the following command:
Server will start sending the following notification messages:
where <sampler-channel> will be replaced by the sampler channel the channel info change occurred. The front-end will have to send the respective command to actually get the channel info. Because these messages will be triggered by LSCP commands issued by other clients rather than real time events happening on the server, it is believed that an empty notification message is sufficient here.
Client may want to be notified when the number of effect sends on a particular sampler channel is changed by issuing the following command:
Server will start sending the following notification messages:
where <channel-id> will be replaced by the numerical ID of the sampler channel, on which the effect sends number is changed and <fx-sends> will be replaced by the new number of effect sends on that channel.
Client may want to be notified when changes were made to effect sends on a a particular sampler channel by issuing the following command:
Server will start sending the following notification messages:
where <channel-id> will be replaced by the numerical ID of the sampler channel, on which an effect send entity is changed and <fx-send-id> will be replaced by the numerical ID of the changed effect send.
Client may want to be notified when the total number of voices on the back-end changes by issuing the following command:
Server will start sending the following notification messages:
where <voices> will be replaced by the new number of all currently active voices.
Client may want to be notified when the total number of disk streams on the back-end changes by issuing the following command:
Server will start sending the following notification messages:
where <streams> will be replaced by the new number of all currently active disk streams.
Client may want to be notified when the number of MIDI instrument maps on the back-end changes by issuing the following command:
Server will start sending the following notification messages:
where <maps> will be replaced by the new number of MIDI instrument maps.
Client may want to be notified when changes were made to MIDI instrument maps on the back-end by issuing the following command:
Server will start sending the following notification messages:
where <map-id> will be replaced by the numerical ID of the MIDI instrument map, for which information changes occurred. The front-end will have to send the respective command to actually get the MIDI instrument map info. Because these messages will be triggered by LSCP commands issued by other clients rather than real time events happening on the server, it is believed that an empty notification message is sufficient here.
Client may want to be notified when the number of MIDI instrument maps on the back-end changes by issuing the following command:
Server will start sending the following notification messages:
where <map-id> is the numerical ID of the MIDI instrument map, in which the nuber of instruments has changed and <instruments> will be replaced by the new number of MIDI instruments in the specified map.
Client may want to be notified when changes were made to MIDI instruments on the back-end by issuing the following command:
Server will start sending the following notification messages:
where <map-id> will be replaced by the numerical ID of the MIDI instrument map, in which a MIDI instrument is changed. <bank> and <program> specifies the location of the changed MIDI instrument in the map. The front-end will have to send the respective command to actually get the MIDI instrument info. Because these messages will be triggered by LSCP commands issued by other clients rather than real time events happening on the server, it is believed that an empty notification message is sufficient here.
Client may want to be notified when changes to the global settings of the sampler were made by issuing the following command:
Server will start sending the following types of notification messages:
Client may want to be notified when the number of instrument directories in a particular directory in the instruments database is changed by issuing the following command:
Server will start sending the following notification messages:
where <dir-path> will be replaced by the absolute path name of the directory in the instruments database, in which the number of directories is changed.
Note that when a non-empty directory is removed, this event is not sent for the subdirectories in that directory.
Client may want to be notified when changes were made to directories in the instruments database by issuing the following command:
Server will start sending the following notification messages:
where <dir-path> will be replaced by the absolute path name of the directory, for which information changes occurred. The front-end will have to send the respective command to actually get the updated directory info. Because these messages will be triggered by LSCP commands issued by other clients rather than real time events happening on the server, it is believed that an empty notification message is sufficient here.
where <old-dir-path> is the old absolute path name of the directory (encapsulated into apostrophes), which name is changes and <new-name> is the new name of the directory, encapsulated into apostrophes.
Client may want to be notified when the number of instruments in a particular directory in the instruments database is changed by issuing the following command:
Server will start sending the following notification messages:
where <dir-path> will be replaced by the absolute path name of the directory in the instruments database, in which the number of instruments is changed.
Note that when a non-empty directory is removed, this event is not sent for the instruments in that directory.
Client may want to be notified when changes were made to instruments in the instruments database by issuing the following command:
Server will start sending the following notification messages:
where <instr-path> will be replaced by the absolute path name of the instrument, which settings are changed. The front-end will have to send the respective command to actually get the updated directory info. Because these messages will be triggered by LSCP commands issued by other clients rather than real time events happening on the server, it is believed that an empty notification message is sufficient here.
where <old-instr-path> is the old absolute path name of the instrument (encapsulated into apostrophes), which name is changes and <new-name> is the new name of the instrument, encapsulated into apostrophes.
Client may want to be notified when the status of particular database instruments job is changed by issuing the following command:
Server will start sending the following notification messages:
where <job-id> will be replaced by the numerical ID of the job, which status is changed. The front-end will have to send the respective command to actually get the status info. Because these messages will be triggered by LSCP commands issued by other clients rather than real time events happening on the server, it is believed that an empty notification message is sufficient here.
Client may want to be notified when the number of effect instances is changed by issuing the following command:
Server will start sending the following notification messages:
where <instances> will be replaced by the new number of effect instances.
Client may want to be notified when changes were made to effect instances on the back-end by issuing the following command:
Server will start sending the following notification messages:
where <instance-id> will be replaced by the numerical ID of the effect instance.
Client may want to be notified when the number of send effect chains is changed by issuing the following command:
Server will start sending the following notification messages:
where <device-id> will be replaced by the numerical ID of the audio output device, in which the number of send effect chains is changed and <chains> will be replaced by the new number of send effect chains.
Client may want to be notified when changes were made to send effect chains on the back-end by issuing the following command:
Server will start sending the following notification messages:
Client may want to be notified of miscellaneous and debugging events occurring at the server by issuing the following command:
Server will start sending the following notification messages:
where <string> will be replaced by whatever data server wants to send to the client. Client MAY display this data to the user AS IS to facilitate debugging.
As there is so far no method of authentication and authorization defined and so not required for a client applications to succeed to connect, running LinuxSampler might be a security risk for the host system the LinuxSampler instance is running on.
This document has benefited greatly from the comments of the following people, discussed on the LinuxSampler developer's mailing list:
| [RFC20] | UCLA, "ASCII format for Network Interchange", RFC 20, 1969. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, 1997. |
| [RFC2234] | Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications", RFC 2234, 1997. |
| [RFC793] | Defense Advanced Research Projects Agency, "TRANSMISSION CONTROL PROTOCOL", RFC 793, 1981. |