www.enchantedage.com

It used to be, a microprocessor was simple. It had instructions like "Load the accumulator from the address stored in the X register (LDA(X))." Or "Add register B to register A (ADD B, A)." And that was pretty much it. Time marched on, and we got more esoteric instructions, like "load effective address of scaled register indirect with offset" (LEA eax, [ebx*8+ecx]).

2009-03-12 latency2.txt README -- jwatte@forterrainc.com

This program measures scheduling latency/jitter for a CPU bound process on a UNIX system. It is intended to determine the suitability of various virtualization products to hosting real-time processes such as game servers. To compile it, use g++ (make sure it has been properly installed!):

$ g++ -o latency2 latency2.cpp

I want to implement my own CSettingsStore that stores data in a file in local application data, rather than the registry. (I note that the documentation claims this is a good idea from a security point of view, but I'm doing it for other reasons).

To implement a GUI, there are a number of widgets provided in the support library (text edit box, rotary knob, slider, selector, pushbutton, checkbox, etc). Given that ItfWindowSlave interface, a plug-in can also implement custom widgets. The widgets, in turn, use the retained-mode scene graph to describe what they look like.

A plug-in can be called upon to open a GUI representation of its parameters. While the support library will provide a default GUI for a plug-in that doesn't want to customize itself, most plug-ins want to do something fancier.

A number of interfaces exist as support for other interfaces in SAPS. These are collected below.

class ItfAddressable
{
  public:
    /* Where do I post messages to if I want to send a message to this target? */
    virtual Address     Address() = 0;
};
 
class ItfBlock
{
  public:
    /* Read the block -- a pointer to the beginning of the data. */

Plug-ins are broken into two parts: The part of being a "plug-in" (a DLL or .so that is hosted in a host process), and the part of being an "effect" (an object that can process audio or MIDI data). A single plug-in can provide multiple effects. This allows for code re-use, allows you to wrap some other API into a single plug-in for SAPS.

There are only a few basic types used in SAPS.

Various parts of the SAPS API are described as C++ pure abstract classes. These are similar to interfaces as used in some approaches (COM, .NET) in that the define the ABI and intended functionality of different entities, but do not define anything about the implementation.

This proposal is now obsolete. but served to start the discussion.