With 3.0 release, PRSD Studio was renamed to perClass. Due to major upgrade
of the execution runtime, the 3.0 release brings some C API changes and
interface polishing. Most of the Matlab API remains unchanged so almost all
existing 2.x user scripts will keep running. Moving from PRSD Studio 2.x
to perClass 3.x is a matter of minutes.

It consists of three steps:

renaming function and macro names

update calls for few functions that changed interface. The interface changes are related to introduction of data types (double, single, int) and to change in memory scheme presented by the custom application to the perClass runtime

changing the header file and library names in your custom projects

Optionally, get familiar with the new functionality available in the
perClass runtime.

As a convention, perclass (small letters) is consistently used everywhere
in the programing API and file names. In this way, we avoid ambiguity as
some operating systems require, some preserve and others don't preserve the
case.

The mixed case perClass is only used as a name of the software in writing.

In the Matlab toolbox, the functions starting with prsd or prsd_ prefix
were renamed using the sd prefix. All renamed functions are only
auxiliary providing seldom used functionality like demo examples of license
activation. The most of PRSD Studio 2.x user-scripts do not need to be
updated to transfer to perClass 3.0. The sd prefix stands for "system
design" and is used avoid clashes in Matlab namespace.

sd_AttachMemToInput and sd_AttachMemToOutput functions take two parameters less and assume different memory ordering of application data buffer

sd_BufNew and sd_BufNewReferringTo requires one new parameter specifying data type (see below). The later function also expects different memory ordering.

to support multiple data types prsd_BufGetValue is replaced by sd_BufGetValueDouble, sd_BufGetValueSingle and sd_BufGetValueInt. Analogously for prsd_BufSetValue

Detailed explanation:

Memory scheme, assumed by the perClass runtime, was changed to reflect the
most common situation where all features of one measurement are stored in
memory together. When attaching perClass runtime to application memory, the
assumption is that the memory block contains all features of the first
sample, then of the second sample etc. In other words, the offset to next
feature is 1 and offset to next sample is equal to the number of features.

Therefore, the perClass 3.0 functions attaching the memory to pipeline
sd_AttachMemToInput and sd_AttachMemToOutput now require less
parameters. Apart of the kernel and pipeline, only the data pointer,
sample size and feature size is needed. The two additional parameters, used
in PRSD Studio 2.x API, namely the sample and feature offsets are
removed. Please note that, strictly speaking, feature size could be also
inferred. perClass API requires that user provides both sample and feature
size of the application buffer being attached. In this way, the feature
size is provided explicitly and potential mismatch with pipeline
dimensionality may be easily found.

perClass 3.x pipelines support use of different data types. By default
double precision is used for data and integer for decisions. Data type is
represented by macros SD_DOUBLE, SD_SINGLE and SD_INT. Input and
output data type of a pipeline is returned by the sd_GetInputType and
sd_GetOutputType calls, respectively. Data type is also included in the
buffer constructor functions sd_BufNew
and sd_BufNewReferringTo.

perClass runtime now provides cross-platform implementation of
high-precision timers accessible through sd_Tic and sd_Toc
functions. sd_Toc returns the time in seconds elapsed from the previous
sd_Tic call. The functions cannot be nested.