While probabily easy to use for most of the users, this solution had its own problems, like the difficulties in handling the configuration at the patch level and at the Max level together (see the never ending bugs in the declare object).
Moreover, moving to an open, client/server portable architecure made the hardware dedicated configuration panel clearly unfeasible; FST release support seven different audio system, in five different platforms, and support three different version of Max, each implemented in a different graphic interface environment; only this would means more than twenty specialized panels to be implemented in three different windowing systems or graphic interface environment; and of course, this is only the beginning; we will add other devices, and users also can add new devices and audio channels.
Also, not all the clients of FTS are graphic applications; FTS is used now in a number of embedded applications, where a GUI is not available or wished, and a non graphical configuration tools is mandatory.
The solution choosen was to define an extensible textual language in which configuration commands could be written, together with a number of well documented and consistent way to feed FTS with configuraton commands written in this language.
The definition of the language fix the syntax and the structure of the configuration commands, but not the semantic; different commands are defined by different FTS subsystems to set different operational conditions.
The main idea behind UCS is to offer to the different kind of FTS users a complete flexibility for what regard where the configuration is defined; for example, who use FTS embedded in final applications, may want to include the configuration commands in the executable itself; users of stable installations may find handy to put the configuration commands in a configuration file, while Max users may want to put the configuration commands in a Max itself, to simplify the packaging of a composition; finally, user interface gurus may want to write control client or specialized GUI to change the configuration; all these users can find in a UCS the simplest way to satisfy their requests.
There many ways to represent an UCS commands, depending on the context; it can be text, in .pat file, or in file in the .min format, or it can be stored as a C source file, in the client/server communication protocol format, or text in a message box.
All this different representation have something in common, that is the fact that they all can represent the same structure, with different concrete syntax.
The structure of a UCS command is simply a list of values, each of them can be a symbol (string), an integer or a float; the first two values must be symbols.
The meaning of the command is given by the first two symbol argument (symbols), the other values represent the argument of the command.
Remember that other commands may be added by user objects or modules. In the following we document the main UCS commands.
help
Print a list of UCS commands defined in the running FTS.
Use this command to have the complete list of UCS commands availables
in the FTS release installed in your site.
Device Configuration
Device Configurations means to tell to FTS which devices to open
and use for the various I/O purpose.
This commands are going to change (and simplify) in the next release;
they are documented anyway in order to make possible to write different
configuration also with this release.
open class class-name [option-name option-value] ...
Open a device class; a device class represent a class or collection of devices, like a multi-channel dac or a file system, or so on. To open a device class means to perform all the initialization operation needed to be able to open a device of the class.
The recomended option format is a list of pairs name of the option/value of the option.Depending on the device class, some of the options may be parameter that apply to all the device of the class; for example, sampling rate usually is a class parameter that apply to all the available dac channels.
close class class-name
Close a device class; a device class should be closed at system shutdown or when not needed any more. The proper action will be taken by the fts kernel to free all the resources used by the class.
open device logical-device [index] class-name [option-name option-value] ...
Open a device of class class-name with the given options, and install it as the logical device logical-device, index index.
A logical device essentially is a device variable; such variables are defined by FTS and application modules, and usually correspond to well defined purposes; for example, the physical device stored as logical device "audio-out" is the device used for the audio output by the FTS audio system; some of the logical device can be tables of devices, to include the case of multi-channels device; in this case the index index is used to specify which element of the table we refer to.
close device logical-device [index]
Close the physical device stored in logical device logical-device.
set sample_rate sr
Set the FTS sample rate to sr; note that you probabily have to set the sampling rate also for the audio output devices; this sampling rate is the one at which FTS compute elapsed time, and not necessary the one used for devices.
set latency latency
Se the FTS latency; this paramenter is valid only in multi-processor configurations, and should be set in all the processor. Latency is the length of the virtual fifo that connect two processors; it was called advance in the Max/Fts 0.26 and older releases; note that the this parameter do not include the length of the fifo that connect dacs and adcs to FTS; they can be set as device or device class opening options. This parameter can be changed dynamically.
set msgmode msg-mode
It set the execution mode of the FTS message system; if the value of the
msg-mode parameter is check the arguments of every message
are tested at run time; if it is fast no check is performed at
run time, and type checking is perfomed only at connection time.
In practice, the check mode will find most of the object programmer
programming error, while the fast mode will find only patch programming
error.
Note that the transition from check to fast is autorized
at run time, while the inverse transition will not completely work,
i.e. not all the checks will be done.
The check mode cause a 50% perfomance hit in the control part
of a patch.
Configuration Information
show welcome
Print the FTS welcome message; the welcome message include generic release
information; modules and application can add some text to the welcome
message by using the fts_add_welcome function.
show modules
Print the list of installed modules, by name. It is intended for debugging purposes.
show scheduling
Print the static scheduling computed at boot time by the scheduler. It is intended for debugging purposes.
show schedinfo
Print all the scheduling declarations. It is intended for debugging purposes.
Configuration File
A UCS command in a configuration file can be represented just
by the string "ucs" followed by the number of processor where
the command should be executed (zero for monoprocessor systems),
and followed by the command itself; the command will be executed
just after the FTS startup.
Max Patches
A UCS command can be sent to an ucs object,
as a standard Max message.
C Function Call
The FTS Kernel provide a function call to execute an UCS
configuration command directly from the user code, like
from an user object.
see the
FTS Kernel Reference Manual
for more details.
Client Messages
UCS is installed as a server subsystem; messages to the 'u' subsystem,
with a void command, are interpreted as UCS commands; actually,
the UCS command in the configuration file correspond exactly to client
messages.
A client application can hardcode configuration commands in its executable
by sending this kind of client messages.
See
the C Client Library Reference Manual for more informations.
Authors : Maurizio De Cecco, François Déchelle
Copyright © 1995 IRCAM.