LinuxSampler Developers C. Schoenebeck Internet-Draft Interessengemeinschaft Software Intended status: Standards Track Engineering e. V. Expires: June 30, 2007 December 27, 2006 LinuxSampler Control Protocol LSCP 1.2 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 30, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Schoenebeck Expires June 30, 2007 [Page 1] Internet-Draft LinuxSampler Control Protocol December 2006 Abstract 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. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 5 2. Versioning of this specification . . . . . . . . . . . . . . 6 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Focus of this protocol . . . . . . . . . . . . . . . . . . . 8 5. Communication Overview . . . . . . . . . . . . . . . . . . . 9 5.1. Request/response communication method . . . . . . . . . . 9 5.1.1. Result format . . . . . . . . . . . . . . . . . . . . 10 5.2. Subscribe/notify communication method . . . . . . . . . . 12 6. Description for control commands . . . . . . . . . . . . . . 14 6.1. Ignored lines and comments . . . . . . . . . . . . . . . 14 6.2. Configuring audio drivers . . . . . . . . . . . . . . . . 14 6.2.1. Getting amount of available audio output drivers . . 15 6.2.2. Getting all available audio output drivers . . . . . 15 6.2.3. Getting information about a specific audio output driver . . . . . . . . . . . . . . . . . . . . . . . 15 6.2.4. Getting information about specific audio output driver parameter . . . . . . . . . . . . . . . . . . 16 6.2.5. Creating an audio output device . . . . . . . . . . . 20 6.2.6. Destroying an audio output device . . . . . . . . . . 21 6.2.7. Getting all created audio output device count . . . . 22 6.2.8. Getting all created audio output device list . . . . 22 6.2.9. Getting current settings of an audio output device . 22 6.2.10. Changing settings of audio output devices . . . . . . 24 6.2.11. Getting information about an audio channel . . . . . 25 6.2.12. Getting information about specific audio channel parameter . . . . . . . . . . . . . . . . . . . . . . 26 6.2.13. Changing settings of audio output channels . . . . . 28 6.3. Configuring MIDI input drivers . . . . . . . . . . . . . 29 6.3.1. Getting amount of available MIDI input drivers . . . 30 6.3.2. Getting all available MIDI input drivers . . . . . . 30 6.3.3. Getting information about a specific MIDI input driver . . . . . . . . . . . . . . . . . . . . . . . 31 6.3.4. Getting information about specific MIDI input driver parameter . . . . . . . . . . . . . . . . . . 32 6.3.5. Creating a MIDI input device . . . . . . . . . . . . 34 6.3.6. Destroying a MIDI input device . . . . . . . . . . . 35 6.3.7. Getting all created MIDI input device count . . . . . 36 Schoenebeck Expires June 30, 2007 [Page 2] Internet-Draft LinuxSampler Control Protocol December 2006 6.3.8. Getting all created MIDI input device list . . . . . 36 6.3.9. Getting current settings of a MIDI input device . . . 37 6.3.10. Changing settings of MIDI input devices . . . . . . . 38 6.3.11. Getting information about a MIDI port . . . . . . . . 38 6.3.12. Getting information about specific MIDI port parameter . . . . . . . . . . . . . . . . . . . . . . 39 6.3.13. Changing settings of MIDI input ports . . . . . . . . 41 6.4. Configuring sampler channels . . . . . . . . . . . . . . 42 6.4.1. Loading an instrument . . . . . . . . . . . . . . . . 42 6.4.2. Loading a sampler engine . . . . . . . . . . . . . . 43 6.4.3. Getting all created sampler channel count . . . . . . 44 6.4.4. Getting all created sampler channel list . . . . . . 44 6.4.5. Adding a new sampler channel . . . . . . . . . . . . 44 6.4.6. Removing a sampler channel . . . . . . . . . . . . . 45 6.4.7. Getting amount of available engines . . . . . . . . . 46 6.4.8. Getting all available engines . . . . . . . . . . . . 46 6.4.9. Getting information about an engine . . . . . . . . . 47 6.4.10. Getting sampler channel information . . . . . . . . . 48 6.4.11. Current number of active voices . . . . . . . . . . . 51 6.4.12. Current number of active disk streams . . . . . . . . 51 6.4.13. Current fill state of disk stream buffers . . . . . . 52 6.4.14. Setting audio output device . . . . . . . . . . . . . 53 6.4.15. Setting audio output type . . . . . . . . . . . . . . 53 6.4.16. Setting audio output channel . . . . . . . . . . . . 54 6.4.17. Setting MIDI input device . . . . . . . . . . . . . . 55 6.4.18. Setting MIDI input type . . . . . . . . . . . . . . . 56 6.4.19. Setting MIDI input port . . . . . . . . . . . . . . . 56 6.4.20. Setting MIDI input channel . . . . . . . . . . . . . 57 6.4.21. Setting channel volume . . . . . . . . . . . . . . . 58 6.4.22. Muting a sampler channel . . . . . . . . . . . . . . 58 6.4.23. Soloing a sampler channel . . . . . . . . . . . . . . 59 6.4.24. Assigning a MIDI instrument map to a sampler channel . . . . . . . . . . . . . . . . . . . . . . . 60 6.4.25. Adding an effect send to a sampler channel . . . . . 61 6.4.26. Removing an effect send from a sampler channel . . . 62 6.4.27. Getting amount of effect sends on a sampler channel . 63 6.4.28. Listing all effect sends on a sampler channel . . . . 63 6.4.29. Getting effect send information . . . . . . . . . . . 64 6.4.30. Altering effect send's audio routing . . . . . . . . 65 6.4.31. Resetting a sampler channel . . . . . . . . . . . . . 66 6.5. Controlling connection . . . . . . . . . . . . . . . . . 66 6.5.1. Register front-end for receiving event messages . . . 66 6.5.2. Unregister front-end for not receiving event messages . . . . . . . . . . . . . . . . . . . . . . 67 6.5.3. Enable or disable echo of commands . . . . . . . . . 68 6.5.4. Close client connection . . . . . . . . . . . . . . . 68 6.6. Global commands . . . . . . . . . . . . . . . . . . . . . 69 6.6.1. Current number of active voices . . . . . . . . . . . 69 Schoenebeck Expires June 30, 2007 [Page 3] Internet-Draft LinuxSampler Control Protocol December 2006 6.6.2. Maximum amount of active voices . . . . . . . . . . . 69 6.6.3. Reset sampler . . . . . . . . . . . . . . . . . . . . 69 6.6.4. General sampler informations . . . . . . . . . . . . 70 6.7. MIDI Instrument Mapping . . . . . . . . . . . . . . . . . 70 6.7.1. Create a new MIDI instrument map . . . . . . . . . . 71 6.7.2. Delete one particular or all MIDI instrument maps . . 72 6.7.3. Get amount of existing MIDI instrument maps . . . . . 72 6.7.4. Getting all created MIDI instrument maps . . . . . . 73 6.7.5. Getting MIDI instrument map information . . . . . . . 73 6.7.6. Renaming a MIDI instrument map . . . . . . . . . . . 74 6.7.7. Create or replace a MIDI instrument map entry . . . . 74 6.7.8. Getting ammount of MIDI instrument map entries . . . 77 6.7.9. Getting indeces of all entries of a MIDI instrument map . . . . . . . . . . . . . . . . . . . 78 6.7.10. Remove an entry from the MIDI instrument map . . . . 78 6.7.11. Get current settings of MIDI instrument map entry . . 79 6.7.12. Clear MIDI instrument map . . . . . . . . . . . . . . 81 7. Command Syntax . . . . . . . . . . . . . . . . . . . . . . . 82 8. Events . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 8.1. Number of audio output devices changed . . . . . . . . . 93 8.2. Audio output device's settings changed . . . . . . . . . 93 8.3. Number of MIDI input devices changed . . . . . . . . . . 93 8.4. MIDI input device's settings changed . . . . . . . . . . 94 8.5. Number of sampler channels changed . . . . . . . . . . . 94 8.6. Number of active voices changed . . . . . . . . . . . . . 94 8.7. Number of active disk streams changed . . . . . . . . . . 95 8.8. Disk stream buffer fill state changed . . . . . . . . . . 95 8.9. Channel information changed . . . . . . . . . . . . . . . 95 8.10. Total number of active voices changed . . . . . . . . . . 96 8.11. Number of MIDI instrument maps changed . . . . . . . . . 96 8.12. MIDI instrument map information changed . . . . . . . . . 96 8.13. Number of MIDI instruments changed . . . . . . . . . . . 97 8.14. MIDI instrument information changed . . . . . . . . . . . 97 8.15. Miscellaneous and debugging events . . . . . . . . . . . 98 9. Security Considerations . . . . . . . . . . . . . . . . . . . 99 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 102 Intellectual Property and Copyright Statements . . . . . . . . . 103 Schoenebeck Expires June 30, 2007 [Page 4] Internet-Draft LinuxSampler Control Protocol December 2006 1. Requirements notation 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), thus the following example: C: "some line" "another line" must actually be interpreted as client sending the following message: "some lineanother line" where symbolizes the carriage return character and the line feed character as defined in the ASCII standard. Due to technical reasons, messages can arbitrary be fragmented, means the following example: S: "abcd" could also happen to be sent in three messages like in the following sequence scenario: o server sending message "a" o followed by a delay (pause) with arbitrary duration o followed by server sending message "bcd" o again followed by a delay (pause) with arbitrary duration o followed by server sending the message "" where again and symbolize the carriage return and line feed characters respectively. Schoenebeck Expires June 30, 2007 [Page 5] Internet-Draft LinuxSampler Control Protocol December 2006 2. Versioning of this specification 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: "1.2" 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: 1. The frontend's LSCP major version and the sampler's LSCP major version are exactly equal. 2. The frontend's LSCP minor version is less or equal than the sampler's LSCP minor version. Compatibility can only be claimed if both rules are true. The frontend can use the "GET SERVER INFO" (Section 6.6.4) command to get the version of the LSCP specification the sampler complies with. Schoenebeck Expires June 30, 2007 [Page 6] Internet-Draft LinuxSampler Control Protocol December 2006 3. Introduction 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. Schoenebeck Expires June 30, 2007 [Page 7] Internet-Draft LinuxSampler Control Protocol December 2006 4. Focus of this protocol 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. Schoenebeck Expires June 30, 2007 [Page 8] Internet-Draft LinuxSampler Control Protocol December 2006 5. Communication Overview 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. 5.1. Request/response communication method 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. Schoenebeck Expires June 30, 2007 [Page 9] Internet-Draft LinuxSampler Control Protocol December 2006 5.1.1. Result format Result set could be one of the following types: 1. Normal 2. Warning 3. Error Warning and Error result sets MUST be single line and have the following format: o "WRN::" o "ERR::" Where and are numeric unique identifiers of the warning or error and and are human readable descriptions of the warning or error respectively. Examples: C: "LOAD INSTRUMENT '/home/me/Boesendorfer24bit.gig" 0 0 S: "WRN:32:This is a 24 bit patch which is not supported natively yet." C: "GET AUDIO_OUTPUT_DRIVER_PARAMETER INFO ALSA EAR" S: "ERR:3456:Audio output driver 'ALSA' does not have a parameter 'EAR'." C: "GET AUDIO_OUTPUT_DEVICE INFO 123456" S: "ERR:9:There is no audio output device with index 123456." Normal result sets could be: 1. Empty 2. Single line 3. Multi-line 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 Schoenebeck Expires June 30, 2007 [Page 10] Internet-Draft LinuxSampler Control Protocol December 2006 set has the following format: "OK" Example: C: "SET AUDIO_OUTPUT_DEVICE_PARAMETER 0 CHANNELS=4" S: "OK" 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: C: "GET AUDIO_OUTPUT_DEVICE INFO 0" S: "DRIVER: ALSA" "CHANNELS: 2" "SAMPLERATE: 44100" "ACTIVE: true" "FRAGMENTS: 2" "FRAGMENTSIZE: 128" "CARD: '0,0'" "." In addition to above mentioned formats, warnings and empty result sets MAY be indexed. In this case, they have the following formats respectively: o "WRN[]::" o "OK[]" where is command specific and is used to indicate channel number that the result set was related to or other integer value. Schoenebeck Expires June 30, 2007 [Page 11] Internet-Draft LinuxSampler Control Protocol December 2006 Each line of the result set MUST end with . Examples: C: "ADD CHANNEL" S: "OK[12]" C: "CREATE AUDIO_OUTPUT_DEVICE ALSA SAMPLERATE=96000" S: "WRN[0]:32:Sample rate not supported, using 44100 instead." 5.2. Subscribe/notify communication method 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: SUBSCRIBE where 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: NOTIFY:: where uniquely identifies the event that has occurred and is event specific. Several rules must be followed by the server when generating events: 1. Events MUST NOT be sent to any client who has not issued an appropriate SUBSCRIBE command. 2. Events MUST only be sent using the same connection that was used to subscribe to them. 3. When response is being sent to the client, event MUST be inserted in the stream before or after the response, but NOT in the middle. Same is true about the response. It should never be Schoenebeck Expires June 30, 2007 [Page 12] Internet-Draft LinuxSampler Control Protocol December 2006 inserted in the middle of the event message as well as any other response. If the client is not interested in a particular event anymore it MAY issue UNSUBSCRIBE command using the following syntax: UNSUBSCRIBE where 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: NOTIFY:CHANNEL_BUFFER_FILL:4 [35]62%,[33]80%,[37]98% 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. Schoenebeck Expires June 30, 2007 [Page 13] Internet-Draft LinuxSampler Control Protocol December 2006 6. Description for control commands 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" (Section 6.4.10) or "GET ENGINE INFO" (Section 6.4.9)) lead to multiple-line responses. In this case LinuxSampler signals the end of the response by a "." (single dot) line. 6.1. Ignored lines and comments 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. 6.2. Configuring audio drivers 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. Schoenebeck Expires June 30, 2007 [Page 14] Internet-Draft LinuxSampler Control Protocol December 2006 6.2.1. Getting amount of available audio output drivers Use the following command to get the number of audio output drivers currently available for the LinuxSampler instance: GET AVAILABLE_AUDIO_OUTPUT_DRIVERS Possible Answers: LinuxSampler will answer by sending the number of audio output drivers. Example: C: "GET AVAILABLE_AUDIO_OUTPUT_DRIVERS" S: "2" 6.2.2. Getting all available audio output drivers Use the following command to list all audio output drivers currently available for the LinuxSampler instance: LIST AVAILABLE_AUDIO_OUTPUT_DRIVERS Possible Answers: LinuxSampler will answer by sending comma separated character strings, each symbolizing an audio output driver. Example: C: "LIST AVAILABLE_AUDIO_OUTPUT_DRIVERS" S: "ALSA,JACK" 6.2.3. Getting information about a specific audio output driver Use the following command to get detailed information about a specific audio output driver: GET AUDIO_OUTPUT_DRIVER INFO Where is the name of the audio output driver, returned by the "LIST AVAILABLE_AUDIO_OUTPUT_DRIVERS" (Section 6.2.2) command. Possible Answers: Schoenebeck Expires June 30, 2007 [Page 15] Internet-Draft LinuxSampler Control Protocol December 2006 LinuxSampler will answer by sending a separated list. Each answer line begins with the information category name followed by a colon and then a space character and finally the info character string to that info category. At the moment the following information categories are defined: DESCRIPTION - character string describing the audio output driver VERSION - character string reflecting the driver's version PARAMETERS - comma separated list of all parameters available for the given audio output driver, at least parameters 'channels', 'samplerate' and 'active' are offered by all audio output drivers The mentioned fields above don't have to be in particular order. Example: C: "GET AUDIO_OUTPUT_DRIVER INFO ALSA" S: "DESCRIPTION: Advanced Linux Sound Architecture" "VERSION: 1.0" "PARAMETERS: DRIVER,CHANNELS,SAMPLERATE,ACTIVE,FRAGMENTS, FRAGMENTSIZE,CARD" "." 6.2.4. Getting information about specific audio output driver parameter Use the following command to get detailed information about a specific audio output driver parameter: GET AUDIO_OUTPUT_DRIVER_PARAMETER INFO