FTS 1.5.0 beta (Montepulciano) Release Notes

Highlights

Montepulciano is just another of the great tuscany wines you can have in the Siena area.

This release include a small number of bug fixes, some new object library, support for the new Sgi audio library and dynamic loading.

Starting from this release, FTS will only run on standard platforms including a complete ANSI-C compiler and a complete libc library, including access to the file system and to standard system resources; the only kind of parallelism supported will be based on SMP architectures.

In more specific terms, it means that this release, and all the future releases, will not run on the ISPW platform.

Also, it means that object programmer are free to access the whole set of libc and filesystem functionalities.

Also, a small number of incompatible change in the API has been done to suppress some old ISPW dependent weirdness ; see the paragraph below.

Platforms

This release is distributed with different binaries for Sgi IRIX 5.3, 6.2 and 6.3/6.4 machines.

The 6.3/6.4 version support the new audio library, and so the ADAT I/O available on some of the machines; for this release, FTS will always use only the default audio device for input and output, so the number of channels is limited to 8 in and 8 out (you have to set the default audio device with the audiopanel application); future releases will support multi-device I/O.

All the different binaries and libraries for SGI are included in a single distribution; take care during the installation process to be sure that the ftsArch resource is set to the good value, otherwise you will run the wrong binary (getting an unexpected lower performance); see the INSTALL file for further details.

Time

Release 1.5.0 included a small change in time related APIs: the C type for time is now double, and not float; all the function calls are changed accordingly.

MIDI

A nasty bug in the MIDI module has been fixed: this bug caused FTS to crash in some case when non consistent MIDI data was received; this in particular could happen with wrong serial to midi cables and wrong MIDI configuration.

New Objects

The newiana~ object by Teodor Teodoroff, and the Gist package by Gerard Eckel have been added to the standard distribution.

Dynamic Loading

A first experimental and limited implementation of dynamic loading have been added to fts.

Dynamic loading is organized around the concept of module, in the same way the static linking is organized; the programming convention introduced for static linking must be kept for dynamically loadable modules.

A module is a collection of classes; a module is stored as a library; for dynamic linking, a module must be pre-linked to a DSO (dynamic shared object) format, using the ld command (the scripts and Makefiles has been updated to do so).

In order to use the classes in the module, a declaration for the class must be created (or loaded); a class declaration is an object named "class", with three arguments: the class name, the module name and an optional file name (that default to lib.so).

For example, the object "class frob frob-utils" declare a class named "frob", that is implemented in the module frob-utils, stored on disk as a .so file named libfrob-utils.so.

The module is loaded the first time a frob object is created; if you try to create a frob object before creating its declaration, FTS will signal a "object not found" error.

The file argument can be an absolute path name; otherwise, it can be a file name or a relative path; in this case, the .so file is searched in all the directory included in the patchPath resource.

The correct way to deliver a library in this format is to pair the shared library with a .pat file that include all the declarations for this library; so that by loading the declaration patch, all the classes become accessible.

This implementation is limited because, since Max do not guarantee, at the moment, that the order of object creation is respected, it is not possible to guarantee that a declaration is loaded before the objects that need it; in other words, you cannot include a declaration patch in an application, you need to load the declaration patches by hand before loading the application patches; this will be fixed in future releases.

This implementation is experimental, in the sense that declaration formats may change in future releases.

Also, consider that for the moment we don't guarantee binary compatibility between releases, and FTS support more than one binary platform, both on the SGI and on other (coming soon) platforms; so, mark clearly the version and binary platform when distributing shared libraries for FTS.

Development scripts

The make-fts script and the relative FTS libraries are not distributed anymore starting from this release; they are still available for special purpose on case by case base; dynamic loading is the recomended way to use user object libraries.

The script make-fts-lib has been fixed, and extended to support dynamic loading (the .so file is automatically generated).

Incompatible Changes in the Kernel FTS APIs

The fts_malloc and fts_zalloc functions drop the second argument; the second argument was used to require a specific kind of memory on architectures with user visible un-uniform memory architecture, like the C40 or the ISPW, architectures that will be never supported again; so better suppress the argument now than keeping it for the future centuries without a reason.

The sys_log function do not exist anymore; since FTS is now a fully libc environment, you can use a fprintf call on the standard error to get diagnostic printouts.

The FTS profiling system has been removed; on modern platforms the system provide utilities far better than anything we could build for profiling or analysing the FTS performance; see the next paragraph of this release notes about which tools you can use for profiling your objects.

The post function was changed to have the same behaviour than the standard printf; the syntax of the formatting string is the same, and the post function do not add anymore newlines at the end of each printout; this give the object programmer more control on the output; the newline explicitly inserted by the programmer behave as expected in the post window; the same change hold for the welcome messages.

Also, since now the object can include the full supported range of formatting code (the ISPW platform didn't allowed this), the special type specific post function (poststring, postlong, postxlong, postfloat and their cpost counterpart) have been deleted.

Profiling FTS in an SGI machine

There are two kind of profile data you can be interested in; perfomance data, i.e. low overhead, non intrusive data on the actual machine load during a performance, and analysis data, i.e. a deeper analysis on how FTS spend its time.

Perfomance data can be easily obtained with the two utilities gr_osview (or gr_top) and rbview (also callable from the audio panel); the first give you information about machine load (and gr_top divide this load between processors, so you can know if it is really FTS to load the machine); the second give you information about the audio fifo length, and on the number of underrun error FTS got; an underrun error means that FTS was too slow to produce enough samples (or the rest of the system got too much CPU time), and is the equivalent of the old ISPW "dac slip" message.

In order to have a better analysis of the performance of the code, you can use the speedshop suite of analysis tool; speedshop can give you detailed data down to the single line of code, using pixie based or pc-sampling techniques, and/or other data like the number of floating point exception, the primary and secondary cache behaviour and others.

Refer to the correct manual pages; in order to run Max and fts with speedshop, the simplest thing to do is to write a script like this:

#!/bin/sh
exec ssrun  /fts
Call it something like "fts.ss", and run Max with the "-n fts.ss" option.

Finally, if what you want to know is just the absolute performance of a complete application in sample per seconds, you can, as usual, use the profile-dac devices to get it.