INScore saves its state to files containing textual OSC messages. These files can be edited or created from scratch using any text editor. In order to provide users with a scripting language, the OSC syntax has been extended at textual level.
An INScore file is a list of textual expressions. A script expression is:
Messages and variables declarations must be followed by a semicolon, used as statements separator.
Messages are basically OSC messages that support the address extension scheme described in section 16 p.157 and relative addresses that are described below. Messages parameters can be replaced by variables that are evaluated at parsing level. Variables are described in section 17.4.
Using the address extension scheme, a script may be designed to initialize an INScore scene and external applications as well, including on remote hosts.
Initializing a score and an external application listening on port 12000 and running on a remote host named host.adomain.net.
Relative addresses have been introduced to provide more flexibility in the score design process. A relative address starts with ’./’. It is evaluated in the context of the message receiver: a legal OSC address is dynamically constructed using the receiver address that is used to prefix the relative address.
The receiver context may be:
Using a set of messages in different contexts:
Legal OSC addresses that are given as argument of an eval message are not affected by the evaluation.
Using OSC, the message parameters are typed by the OSC protocol. With their textual version, any parameter is converted to an OSC type (i.e. int32, float or string) at parsing level. A special attention must be given to strings in order to discriminate addresses and parameters. Strings intended as parameters must:
Different string parameter
A variable declaration associates a name with a list of parameters or a list of messages. Parameters must follow the rules given in section 17.3. They may include previously declared variables. A message list must be enclosed in parenthesis and a comma must be used as messages separator.
A variable may be used in place of any message parameter. A reference to a variable must have the form $ident where ident is a previously declared variable. A variable is evaluated at parsing level and replaced by its content.
Using a variable to share a common position:
Variables can be used in interaction messages as well, which may also use the variables available in the interaction context (see section 16.5 p.167). To differentiate between a script and an interaction variable, the latter must be quoted to be passed as strings and to prevent their evaluation by the parser.
Using variables in interaction messages: $sx is evaluated at event occurrence and $y is evaluated at parsing level.
Environnement variables are predefined variables available in a script context. They provide information related to the current context. Current environment variables are:
There is nothing to prevent overriding of an environment variable. It’s the script responsibility to handle variable names collisions.
Similarly to message based variables (see section 16.5.5 p.170), a message parameter may also use the result of a get message as parameters specified like a message based variable. The message must be enclosed in parameters with a leading $ sign.
Displaying INScore version using a message parameter:
Message based parameters are evaluated by the parser. Thus when the system state is modified by a script before a message parameter, these modifications won’t be visible at the time of the parameter evaluation because all the messages will be processed by the next time task. For example:
x position of /ITL/scene/foo will be set to x position of /ITL/scene/obj at the time of the script evaluation (that may be different to 0.1).
Note that INScore variables are exported to the current language environment.
A single persistent context is created at application level and shared to each scene.
NOTE Lua support is going to be deprecated and should be removed in a future release.