/*! \page controlin Control Input

Each Synthesis ToolKit instrument exposes its relevant control parameters via public functions such as setFrequency() and controlChange().  Programmers are free to implement the control scheme of their choice in exposing those parameters to the user.

A text-based control protocol called <A HREF="skini.html">SKINI</A> is provided with the Synthesis ToolKit.  SKINI extends the MIDI protocol in incremental ways, providing a text-based messaging scheme in human-readable format and making use of floating-point numbers wherever possible.  Each SKINI message consists  of a message type (e.g., NoteOn, PitchBend), a time specification (absolute or delta), a channel number (scanned as a long integer), and a maximum of two subsequent message-specific field values.  Knowing this, it should be relatively clear what the following SKINI "scorefile" specifies:

\code
NoteOn          0.000082  2  55.0  82.3
NoteOff         1.000000  2  55.0  64.0
NoteOn          0.000082  2  69.0  82.8
StringDetune    0.100000  2  10.0
StringDetune    0.100000  2  30.0
StringDetune    0.100000  2  50.0
StringDetune    0.100000  2  40.0
StringDetune    0.100000  2  22.0
StringDetune    0.100000  2  12.0
NoteOff         1.000000  2  69.0  64.0
\endcode

MIDI messages are easily represented within the SKINI protocol.

The class Messager can be used to acquire and parse MIDI messages from a MIDI device and SKINI messages from STDIN and socket connections.  Incoming messages are acquired asynchronously and saved to an internal message queue of Skini::Message types (MIDI messages are converted to the Skini:Message format).  The user then uses the Messager:popMessage() function to retrieve incoming control messages.  This function does not block, instead returning a message type of zero when no more messages are in the queue.  Many of the example programs included with the ToolKit distribution use a Messager instance to accept control input from the accompanying tcl/tk graphical user interfaces, from external MIDI devices, or from SKINI scorefiles.

In the following example, we'll modify the <TT>bethree.cpp</TT> program from the previous tutorial chapter and incorporate a Messager class to allow control via SKINI messages read from a SKINI file.

\include controlbee.cpp

A realtime control message will usually have a delta time of zero, in which case it is processed as soon as possible.  Non-realtime messages, normally from a scorefile, will usually have non-zero delta times.  The scheme used in this example is designed to work for both scorefile and realtime input types.  When no message is available from the queue, the instrument is "ticked" for DELTA_CONTROL_TICKS and then the queue is checked again.  The value of DELTA_CONTROL_TICKS roughly defines the program "control rate" in a realtime context, though multiple available messages in the queue are processed in immediate succession when their delta time values are zero.

The \c processMessage() function centralizes the handling of control messages.  Other control update schemes can be implemented, perhaps using a separate thread or in the \c main() function, and this function should work in any context.

Assuming the program is compiled as <TT>controlbee</TT> and the SKINI scorefile <A HREF="tutorial/bookert.ski"><TT>bookert.ski</TT></A> is in the <TT>scores</TT> directory, the program can be run as:

\code
controlbee scores/bookert.ski
\endcode

Only a few basic SKINI message type case statements are included in this example.  It is easy to extend the program to support a much more elaborate set of instrument control parameters.

This example could also be easily extended to accept "realtime" control input messages via pipe, socket or MIDI connections.  The Messager class provides Messager::startStdInput(), Messager::startSocketInput(), and Messager::startMidiInput() functions for this purpose.

[<A HREF="multichannel.html">Next tutorial</A>] &nbsp; [<A HREF="tutorial.html">Main tutorial page</A>]
*/
