Version 2.0 proposal (with code listings)

jwatte's picture

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.

As opposed to COM, the lifetime of interfaces in SAPS is defined based on the lifetime of various objects and states. Reference counting, as done in COM, is not part of the SAPS interfaces.

To make implementing a plug-in really easy, a support library is provided (in C++) which makes it very easy to implement a well-behaved plug-in, and only provide the information and functionality you are interested in. The support library provides default behavior for other parts.

SAPS, itself, can be used as a plug-in API. This is used by native SAPS hosts, for example those using the SAPS Hosting library. However, because not every host will support SAPS out of the gate, the intention of the API is to also support using the effect or synth you write from hosts that support VST 2.4, DXi or other popular virtual studio interfaces. This mapping is done by developing an API implementation for the target API, that maps to the SAPS API, and fills in the blanks where the target API misses out on something that is in SAPS, or vice versa. Because SAPS encompasses a large amount of functionality, as learned through dozens of man-years of experience, chances are that if you can express it in SAPS, you can get as rich as possible plug-in for the other APIs as well.

SAPS-090114.zip20.92 KB