Version 4.2.0

This commit is contained in:
Gary Scavone
2009-03-24 23:02:14 -04:00
committed by Stephen Sinclair
parent cf06b7598b
commit a6381b9d38
281 changed files with 17152 additions and 12000 deletions

View File

@@ -17,114 +17,27 @@ StringDetune 0.100000 2 12.0
NoteOff 1.000000 2 69.0 64.0
\endcode
MIDI messages (with the exception of Sysex) are easily represented within the SKINI protocol.
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. 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.
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 a SKINI scorefile.
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.cpp
#include "BeeThree.h"
#include "RtWvOut.h"
#include "Messager.h"
#include "SKINI.msg"
#include <math.h>
int main()
{
// Set the global sample rate before creating class instances.
Stk::setSampleRate( 44100.0 );
Instrmnt *instrument = 0;
RtWvOut *output = 0;
Messager *messager = 0;
bool done = FALSE;
try {
// Define and load the BeeThree instrument
instrument = new BeeThree();
// Define and open the default realtime output device for one-channel playback
output = new RtWvOut(1);
}
catch (StkError &) {
goto cleanup;
}
try {
// Create a Messager instance to read from a redirected SKINI scorefile.
messager = new Messager();
}
catch (StkError &) {
goto cleanup;
}
// Play the instrument until the end of the scorefile.
int i, nTicks, type;
MY_FLOAT byte2, byte3, frequency;
while (!done) {
// Look for new messages and return a delta time (in samples).
type = messager->nextMessage();
if (type < 0)
done = TRUE;
nTicks = messager->getDelta();
try {
for ( i=0; i<nTicks; i++ )
output->tick( instrument->tick() );
}
catch (StkError &) {
goto cleanup;
}
if ( type > 0 ) {
// Process the new control message.
byte2 = messager->getByteTwo();
byte3 = messager->getByteThree();
switch(type) {
case __SK_NoteOn_:
frequency = (MY_FLOAT) 220.0 * pow( 2.0, (byte2 - 57.0) / 12.0 );
instrument->noteOn( frequency, byte3 * ONE_OVER_128 );
break;
case __SK_NoteOff_:
instrument->noteOff( byte3 * ONE_OVER_128 );
break;
case __SK_ControlChange_:
instrument->controlChange( (int) byte2, byte3 );
break;
case __SK_AfterTouch_:
instrument->controlChange( 128, byte2 );
break;
}
}
}
cleanup:
delete instrument;
delete output;
delete messager;
return 0;
}
\endcode
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 scorefile could be redirected to the program as:
\code
controlbee < scores/bookert.ski
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 STDIN, socket, or MIDI connections. The Messager class constructor takes an optional argument consisting of a bitmask of the following options: <TT>STK_PIPE</TT>, <TT>STK_SOCKET</TT>, and/or <TT>STK_MIDI</TT>.
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>]
*/