RealTime Library - Revision history

Daniel Jedlicka: Unified parameter reference style.

2026-04-13T07:11:45Z

Unified parameter reference style.

← Older revision		Revision as of 07:11, 13 April 2026
Line 98:		Line 98:
	</syntaxhighlight>		</syntaxhighlight>

	The player parameter indicates which Player structure is to have its attributes changed. The Tag items indicate the attributes and their new values. If the change is made successfully, then TRUE is returned. FALSE indicates failure. In the fragment above, a wake-up time is requested using the PLAYER_AlarmTime tag. Also, the calling task indicates to the Conductor that it is ready by using the PLAYER_Ready tag (more on this below).		The ''player'' parameter indicates which Player structure is to have its attributes changed. The Tag items indicate the attributes and their new values. If the change is made successfully, then TRUE is returned. FALSE indicates failure. In the fragment above, a wake-up time is requested using the PLAYER_AlarmTime tag. Also, the calling task indicates to the Conductor that it is ready by using the PLAYER_Ready tag (more on this below).

	At this point, the call to Wait(1UL << midiSignal) causes the task to sleep until time = 1000 ticks.		At this point, the call to Wait(1UL << midiSignal) causes the task to sleep until time = 1000 ticks.
Line 195:		Line 195:
	</syntaxhighlight>		</syntaxhighlight>

	The player parameter is a pointer to a Player structure that is linked to the Conductor you want to change. The ti parameter is a time offset used for special cases (typically set to zero). The ''newstate'' parameter is one of the following:		The ''player'' parameter is a pointer to a Player structure that is linked to the Conductor you want to change. The ''ti'' parameter is a time offset used for special cases (typically set to zero). The ''newstate'' parameter is one of the following:
	{\| class="wikitable"		{\| class="wikitable"
	\| CONDSTATE_STOPPED \|\| The clock is not running		\| CONDSTATE_STOPPED \|\| The clock is not running

Daniel Jedlicka: Fixed internal link.

2026-04-13T07:08:22Z

Fixed internal link.

← Older revision		Revision as of 07:08, 13 April 2026
Line 91:		Line 91:
	In the fragment above, the calling task requests a Player with an alarm clock feature by passing the PLAYER_AlarmSigBit tag to CreatePlayer() The ti_Data field of this tag contains the signal bit that will be set by the RealTime Library when the alarm goes off. The PLAYER_AlarmSigTask tag indicates which task will be signaled.		In the fragment above, the calling task requests a Player with an alarm clock feature by passing the PLAYER_AlarmSigBit tag to CreatePlayer() The ti_Data field of this tag contains the signal bit that will be set by the RealTime Library when the alarm goes off. The PLAYER_AlarmSigTask tag indicates which task will be signaled.

	The realtime clock is then started by calling SetConductorState(); [[More About Conductors\|see below]]. This is important since any alarm requests made when the clock is stopped will be ignored.		The realtime clock is then started by calling SetConductorState(); [[#More About Conductors\|see below]]. This is important since any alarm requests made when the clock is stopped will be ignored.

	Finally, the alarm time is set by calling SetPlayerAttrs(). The parameters to this call are:		Finally, the alarm time is set by calling SetPlayerAttrs(). The parameters to this call are:

Daniel Jedlicka: Minor corrections

2026-04-13T07:05:41Z

Minor corrections

← Older revision		Revision as of 07:05, 13 April 2026
Line 91:		Line 91:
	In the fragment above, the calling task requests a Player with an alarm clock feature by passing the PLAYER_AlarmSigBit tag to CreatePlayer() The ti_Data field of this tag contains the signal bit that will be set by the RealTime Library when the alarm goes off. The PLAYER_AlarmSigTask tag indicates which task will be signaled.		In the fragment above, the calling task requests a Player with an alarm clock feature by passing the PLAYER_AlarmSigBit tag to CreatePlayer() The ti_Data field of this tag contains the signal bit that will be set by the RealTime Library when the alarm goes off. The PLAYER_AlarmSigTask tag indicates which task will be signaled.

	The realtime clock is then started by calling SetConductorState(); see below. This is important since any alarm requests made when the clock is stopped will be ignored.		The realtime clock is then started by calling SetConductorState(); [[More About Conductors\|see below]]. This is important since any alarm requests made when the clock is stopped will be ignored.

	Finally, the alarm time is set by calling SetPlayerAttrs(). The parameters to this call are:		Finally, the alarm time is set by calling SetPlayerAttrs(). The parameters to this call are:
Line 208:		Line 208:
	The difference between locating and running requires some explanation. Each Player has a "ready bit" which is used to tell the RealTime Library that the player is ready to receive ticks. This bit is reset each time the library relocates the clock to a new time.		The difference between locating and running requires some explanation. Each Player has a "ready bit" which is used to tell the RealTime Library that the player is ready to receive ticks. This bit is reset each time the library relocates the clock to a new time.

	The reason for the ready bit is that some applications need to find the appropriate location in the multimedia sequence or score before they can start playing at the new location. In some cases this can take a considerable amount of time. Hence, ~~CONDSTATE__LOCATE~~ is used with the ready bit to allow all players that are sharing a timing context to be synchronized together.		The reason for the ready bit is that some applications need to find the appropriate location in the multimedia sequence or score before they can start playing at the new location. In some cases this can take a considerable amount of time. Hence, CONDSTATE_LOCATE is used with the ready bit to allow all players that are sharing a timing context to be synchronized together.

	Players can set the state of their ready bit by using the PLAYER_Ready tag attribute either when the Player is created with CreatePlayer() or later with SetPlayerAttrs(). See the first code fragment above for an example of this.		Players can set the state of their ready bit by using the PLAYER_Ready tag attribute either when the Player is created with CreatePlayer() or later with SetPlayerAttrs(). See the first code fragment above for an example of this.

Daniel Jedlicka: Corrected wrong information in the More About Conductors section.

2026-04-13T06:59:52Z

Corrected wrong information in the More About Conductors section.

Daniel Jedlicka: Corrected wrong information in the Getting Clock Ticks section.

2026-04-13T06:53:06Z

Corrected wrong information in the Getting Clock Ticks section.

Show changes

Daniel Jedlicka: Removed references to struct PlayerInfo because it's in fact called Player.

2026-04-13T06:34:17Z

Removed references to struct PlayerInfo because it's in fact called Player.

← Older revision		Revision as of 06:34, 13 April 2026
Line 5:		Line 5:
	The RealTime Library uses the Conductor structure to manage timing. There can be any number of Conductor structures, each of which represents a separate and independent timing context (i.e. a group of applications that want to be synced together).		The RealTime Library uses the Conductor structure to manage timing. There can be any number of Conductor structures, each of which represents a separate and independent timing context (i.e. a group of applications that want to be synced together).

	Each Conductor can have one or more client applications. A second structure called a ~~PlayerInfo~~ is set up by each client application that wants to get timing information from the Conductor. There is typically one ~~PlayerInfo~~ for each task that wants to get timing information (a task could have more than one but this would be unusual).		Each Conductor can have one or more client applications. A second structure called a Player is set up by each client application that wants to get timing information from the Conductor. There is typically one Player for each task that wants to get timing information (a task could have more than one but this would be unusual).

	Both the Conductor and ~~PlayerInfo~~ structures are dynamic. You never create these structures by allocating and initializing them yourself. The system provides the functions to do this for you. Also, the structures are read-only. To change the fields within these structures, use the system-provided functions and tags.		Both the Conductor and Player structures are dynamic. You never create these structures by allocating and initializing them yourself. The system provides the functions to do this for you. Also, the structures are read-only. To change the fields within these structures, use the system-provided functions and tags.

	An application will usually create a single ~~PlayerInfo~~ structure and then attach it to a Conductor. If the Conductor does not yet exist, it will be created by the system. To create a ~~PlayerInfo~~ structure you call CreatePlayer():		An application will usually create a single Player structure and then attach it to a Conductor. If the Conductor does not yet exist, it will be created by the system. To create a Player structure you call CreatePlayer():

	<syntaxhighlight lang="C" line>		<syntaxhighlight lang="C" line>
	struct ~~PlayerInfo~~ *pi = IRealTime->CreatePlayer(Tag tag, ...);		struct Player *player = IRealTime->CreatePlayer(Tag tag, ...);
	</syntaxhighlight>		</syntaxhighlight>

	This call takes a list of tag items that describe the attributes of the ~~PlayerInfo~~ structure you want to create. (A complete list of all the tags available can be found in the Autodoc for SetPlayerAttrs().) It returns a pointer to the ~~PlayerInfo~~. Here’s a fragment showing how to set up a ~~PlayerInfo~~:		This call takes a list of tag items that describe the attributes of the Player structure you want to create. (A complete list of all the tags available can be found in the Autodoc for the SetPlayerAttrs() function.) It returns a pointer to the Player structure. Here’s a fragment showing how to set up a Player:

	<syntaxhighlight lang="C" line>		<syntaxhighlight lang="C" line>
	struct ~~PlayerInfo~~ *~~pPlayerInfo~~ = IRealTime->CreatePlayer(		struct Player *player = IRealTime->CreatePlayer(
	PLAYER_Name, "My_player",		PLAYER_Name, "My_player",
	PLAYER_Conductor, "My_conductor",		PLAYER_Conductor, "My_conductor",
	TAG_END);		TAG_END);

	if (~~pPlayerInfo~~ != NULL )		if (player != NULL )
	{		{
	// Your real-time application goes here...		// Your real-time application goes here...

	IRealTime->DeletePlayer(~~pPlayerInfo~~);		IRealTime->DeletePlayer(player);
	}		}
	</syntaxhighlight>		</syntaxhighlight>

	In the code above, a ~~PlayerInfo~~ will be created with the name of "My_player". It will be attached to the Conductor structure named "My_conductor". If a Conductor structure named "My_conductor" does not already exist, the system will create one. Other applications could also attach their ~~PlayerInfos~~ to "My_conductor".		In the code above, a Player will be created with the name of "My_player". It will be attached to the Conductor structure named "My_conductor". If a Conductor structure named "My_conductor" does not already exist, the system will create one. Other applications could also attach their Players to "My_conductor".

	When your application finishes, you should delete any ~~PlayerInfos~~ you have created by calling DeletePlayer(). The Conductor will be automatically deleted by the system (however, this won’t happen until '''all''' the ~~PlayerInfos~~ attached to a Conductor are deleted).		When your application finishes, you should delete any Players you have created by calling DeletePlayer(). The Conductor will be automatically deleted by the system (however, this won’t happen until '''all''' the Players attached to a Conductor are deleted).

	Once you have a ~~PlayerInfo~~ and Conductor set up, you can obtain timing pulses for your application. Timing pulses come from underlying timer chips and are passed to your application through the Conductor.		Once you have a Player and Conductor set up, you can obtain timing pulses for your application. Timing pulses come from underlying timer chips and are passed to your application through the Conductor.

	= Getting Clock Ticks =		= Getting Clock Ticks =

Daniel Jedlicka: /* Conductors and Players */ - fixed section heading

2026-04-13T06:27:43Z

Conductors and Players: - fixed section heading

← Older revision		Revision as of 06:27, 13 April 2026
Line 1:		Line 1:
	The RealTime Library provides a convenient, higher-level interface to underlying hardware timers that is easy to use. The library also provides for the distribution of timing pulses to an unlimited number of client applications on a priority basis, thus supporting multitasking in the most robust manner possible.		The RealTime Library provides a convenient, higher-level interface to underlying hardware timers that is easy to use. The library also provides for the distribution of timing pulses to an unlimited number of client applications on a priority basis, thus supporting multitasking in the most robust manner possible.

	= Conductors and ~~PlayerInfos~~ =		= Conductors and Players =

	The RealTime Library uses the Conductor structure to manage timing. There can be any number of Conductor structures, each of which represents a separate and independent timing context (i.e. a group of applications that want to be synced together).		The RealTime Library uses the Conductor structure to manage timing. There can be any number of Conductor structures, each of which represents a separate and independent timing context (i.e. a group of applications that want to be synced together).

Costel Mincea: Text replacement - "" to ""

2025-01-26T19:17:56Z

Text replacement - "<syntaxhighlight>" to "<syntaxhighlight lang="C" line>"

← Older revision		Revision as of 19:17, 26 January 2025
Line 11:		Line 11:
	An application will usually create a single PlayerInfo structure and then attach it to a Conductor. If the Conductor does not yet exist, it will be created by the system. To create a PlayerInfo structure you call CreatePlayer():		An application will usually create a single PlayerInfo structure and then attach it to a Conductor. If the Conductor does not yet exist, it will be created by the system. To create a PlayerInfo structure you call CreatePlayer():

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct PlayerInfo *pi = IRealTime->CreatePlayer(Tag tag, ...);		struct PlayerInfo *pi = IRealTime->CreatePlayer(Tag tag, ...);
	</syntaxhighlight>		</syntaxhighlight>
Line 17:		Line 17:
	This call takes a list of tag items that describe the attributes of the PlayerInfo structure you want to create. (A complete list of all the tags available can be found in the Autodoc for SetPlayerAttrs().) It returns a pointer to the PlayerInfo. Here’s a fragment showing how to set up a PlayerInfo:		This call takes a list of tag items that describe the attributes of the PlayerInfo structure you want to create. (A complete list of all the tags available can be found in the Autodoc for SetPlayerAttrs().) It returns a pointer to the PlayerInfo. Here’s a fragment showing how to set up a PlayerInfo:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct PlayerInfo *pPlayerInfo = IRealTime->CreatePlayer(		struct PlayerInfo *pPlayerInfo = IRealTime->CreatePlayer(
	PLAYER_Name, "My_player",		PLAYER_Name, "My_player",
Line 50:		Line 50:
	The fragment below shows how to set up the library’s alarm clock to signal the calling task at time = 1000 ticks (the fragment assumes that the RealTime Library interface is already obtained).		The fragment below shows how to set up the library’s alarm clock to signal the calling task at time = 1000 ticks (the fragment assumes that the RealTime Library interface is already obtained).

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	// This fragment assumes the that IRealTime is already obtained.		// This fragment assumes the that IRealTime is already obtained.
	int8 midiSignal = IExec->AllocSignal(-1); // Allocate a wake-up signal bit		int8 midiSignal = IExec->AllocSignal(-1); // Allocate a wake-up signal bit
Line 92:		Line 92:

	Finally, the alarm time is set by calling SetPlayerAttrs(). The parameters to this call are:		Finally, the alarm time is set by calling SetPlayerAttrs(). The parameters to this call are:
	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	BOOL result = SetPlayerAttrs(struct PlayerInfo *pi, Tag tag, ...);		BOOL result = SetPlayerAttrs(struct PlayerInfo *pi, Tag tag, ...);
	</syntaxhighlight>		</syntaxhighlight>
Line 110:		Line 110:
	To set up a callback hook, you use the PLAYER_Hook tag with the address of a standard Hook structure as defined in <utilities/hook.h>. This structure contains the address of the code you want to be invoked whenever the RealTime Library updates your Conductor. Here’s a code fragment showing how this is done:		To set up a callback hook, you use the PLAYER_Hook tag with the address of a standard Hook structure as defined in <utilities/hook.h>. This structure contains the address of the code you want to be invoked whenever the RealTime Library updates your Conductor. Here’s a code fragment showing how this is done:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct Task *My_task;		struct Task *My_task;
	int8 My_signal;		int8 My_signal;
Line 160:		Line 160:
	Conductor time equals or exceeds ticks, the hook function signals the main task.		Conductor time equals or exceeds ticks, the hook function signals the main task.

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	// Hook code called whenever the RealTime Library updates Conductor time.		// Hook code called whenever the RealTime Library updates Conductor time.
	// Normally this is 600 times/sec.		// Normally this is 600 times/sec.
Line 192:		Line 192:
	As shown in the examples above, the "state" of the Conductor can be changed at any time by calling SetConductorState(). If the call succeeds, zero is returned:		As shown in the examples above, the "state" of the Conductor can be changed at any time by calling SetConductorState(). If the call succeeds, zero is returned:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	int32 res = IRealTime->SetConductorState(struct PlayerInfo *pi, int32 newstate, int32 ti);		int32 res = IRealTime->SetConductorState(struct PlayerInfo *pi, int32 newstate, int32 ti);
	</syntaxhighlight>		</syntaxhighlight>

Daniel Jedlicka: Fixed typos that probably resulted from OCR.

2023-04-06T08:42:05Z

Fixed typos that probably resulted from OCR.

Frédéric Khannouf: /* Conductors and Playerlnfos */

2020-10-11T18:47:41Z

Conductors and Playerlnfos

← Older revision		Revision as of 18:47, 11 October 2020
Line 1:		Line 1:
	The RealTime Library provides a convenient, higher-level interface to underlying hardware timers that is easy to use. The library also provides for the distribution of timing pulses to an unlimited number of client applications on a priority basis, thus supporting multitasking in the most robust manner possible.		The RealTime Library provides a convenient, higher-level interface to underlying hardware timers that is easy to use. The library also provides for the distribution of timing pulses to an unlimited number of client applications on a priority basis, thus supporting multitasking in the most robust manner possible.

	= Conductors and ~~Playerlnfos~~ =		= Conductors and PlayerInfos =

	The RealTime Library uses the Conductor structure to manage timing. There can be any number of Conductor structures, each of which represents a separate and independent timing context (i.e. a group of applications that want to be synced together).		The RealTime Library uses the Conductor structure to manage timing. There can be any number of Conductor structures, each of which represents a separate and independent timing context (i.e. a group of applications that want to be synced together).

← Older revision		Revision as of 06:59, 13 April 2026
Line 183:		Line 183:
	= More About Conductors =		= More About Conductors =

	It is the job of the Conductor to act as middleman between the Amiga's timing hardware and client tasks represented by ~~PlayerInfo~~ structures. Each Conductor keeps track of:		It is the job of the Conductor to act as middleman between the Amiga's timing hardware and client tasks represented by Player structures. Each Conductor keeps track of:
	* an Exec list of all its client players		* an Exec list of all its client players
	* the state of the conductor (i.e. running, stopped, paused, locating – see below)		* the state of the conductor (i.e. running, stopped, paused, locating – see below)
Line 192:		Line 192:

	<syntaxhighlight lang="C" line>		<syntaxhighlight lang="C" line>
	int32 res = IRealTime->SetConductorState(struct ~~PlayerInfo~~ *pi, int32 newstate, int32 ti);		int32 res = IRealTime->SetConductorState(struct Player *player, int32 newstate, int32 ti);
	</syntaxhighlight>		</syntaxhighlight>

	The pi parameter is a pointer to a ~~PlayerInfo~~ structure that is linked to the Conductor you want to change. The ti parameter is a time offset used for special cases (typically set to zero). The ''newstate'' parameter is one of the following:		The player parameter is a pointer to a Player structure that is linked to the Conductor you want to change. The ti parameter is a time offset used for special cases (typically set to zero). The ''newstate'' parameter is one of the following:
	{\| class="wikitable"		{\| class="wikitable"
	\| ~~CLOCKSTATE_STOPPED~~ \|\| The clock is not running		\| CONDSTATE_STOPPED \|\| The clock is not running
	\|-		\|-
	\| ~~CLOCKSTATE_PAUSED~~ \|\| To the RealTime Library, this is exactly the same as stopped. This is provided as a convenience to those applications that wish to make a distinction between the two.		\| CONDSTATE_PAUSED \|\| To the RealTime Library, this is exactly the same as stopped. This is provided as a convenience to those applications that wish to make a distinction between the two.
	\|-		\|-
	\| ~~CLOCKSTATE_RUNNING~~ \|\| The clock is running and time pulses are being distributed to any client applications (~~PlayerInfos~~) that are ready.		\| CONDSTATE_RUNNING \|\| The clock is running and time pulses are being distributed to any client applications (Players) that are ready.
	\|-		\|-
	\| ~~CLOCKSTATE_LOCATE~~ \|\| This is the same as running with one exception: the clock does not actually start until ''all'' client applications have indicated that they are ready by setting the PLAYER_Ready attribute of their ~~PlayerInfo~~ to TRUE. This allows applications that cannot start immediately to set up before timing pulses actually begin.		\| CONDSTATE_LOCATE \|\| This is the same as running with one exception: the clock does not actually start until ''all'' client applications have indicated that they are ready by setting the PLAYER_Ready attribute of their Player to TRUE. This allows applications that cannot start immediately to set up before timing pulses actually begin.
	\|}		\|}

	The difference between locating and running requires some explanation. Each ~~PlayerInfo~~ has a "ready bit" which is used to tell the RealTime Library that the player is ready to receive ticks. This bit is reset each time the library relocates the clock to a new time.		The difference between locating and running requires some explanation. Each Player has a "ready bit" which is used to tell the RealTime Library that the player is ready to receive ticks. This bit is reset each time the library relocates the clock to a new time.

	The reason for the ready bit is that some applications need to find the appropriate location in the multimedia sequence or score before they can start playing at the new location. In some cases this can take a considerable amount of time. Hence, ~~CLOCKSTATE__LOCATE~~ is used with the ready bit to allow all players that are sharing a timing context to be synchronized together.		The reason for the ready bit is that some applications need to find the appropriate location in the multimedia sequence or score before they can start playing at the new location. In some cases this can take a considerable amount of time. Hence, CONDSTATE__LOCATE is used with the ready bit to allow all players that are sharing a timing context to be synchronized together.

	Players can set the state of their ready bit by using the PLAYER_Ready tag attribute either when the ~~PlayerInfo~~ is created with CreatePlayer() or later with SetPlayerAttrs(). See the first code fragment above for an example of this.		Players can set the state of their ready bit by using the PLAYER_Ready tag attribute either when the Player is created with CreatePlayer() or later with SetPlayerAttrs(). See the first code fragment above for an example of this.

← Older revision		Revision as of 08:42, 6 April 2023
Line 5:		Line 5:
	The RealTime Library uses the Conductor structure to manage timing. There can be any number of Conductor structures, each of which represents a separate and independent timing context (i.e. a group of applications that want to be synced together).		The RealTime Library uses the Conductor structure to manage timing. There can be any number of Conductor structures, each of which represents a separate and independent timing context (i.e. a group of applications that want to be synced together).

	Each Conductor can have one or more client applications. A second structure called a PlayerInfo is set up by each client application that wants to get timing information from the Conductor. There is typically one ~~Playerlnfo~~ for each task that wants to get timing information (a task could have more than one but this would be unusual).		Each Conductor can have one or more client applications. A second structure called a PlayerInfo is set up by each client application that wants to get timing information from the Conductor. There is typically one PlayerInfo for each task that wants to get timing information (a task could have more than one but this would be unusual).

	Both the Conductor and ~~Playerlnfo~~ structures are dynamic. You never create these structures by allocating and initializing them yourself. The system provides the functions to do this for you. Also, the structures are read-only. To change the fields within these structures, use the system-provided functions and tags.		Both the Conductor and PlayerInfo structures are dynamic. You never create these structures by allocating and initializing them yourself. The system provides the functions to do this for you. Also, the structures are read-only. To change the fields within these structures, use the system-provided functions and tags.

	An application will usually create a single PlayerInfo structure and then attach it to a Conductor. If the Conductor does not yet exist, it will be created by the system. To create a PlayerInfo structure you call ~~CreatePlayerO~~:		An application will usually create a single PlayerInfo structure and then attach it to a Conductor. If the Conductor does not yet exist, it will be created by the system. To create a PlayerInfo structure you call CreatePlayer():

	<syntaxhighlight>		<syntaxhighlight>
Line 15:		Line 15:
	</syntaxhighlight>		</syntaxhighlight>

	This call takes a list of tag items that describe the attributes of the ~~Playerlnfo~~ structure you want to create. (A complete list of all the tags available can be found in the Autodoc for SetPlayerAttrs().) It returns a pointer to the PlayerInfo. Here’s a fragment showing how to set up a PlayerInfo:		This call takes a list of tag items that describe the attributes of the PlayerInfo structure you want to create. (A complete list of all the tags available can be found in the Autodoc for SetPlayerAttrs().) It returns a pointer to the PlayerInfo. Here’s a fragment showing how to set up a PlayerInfo:

	<syntaxhighlight>		<syntaxhighlight>
Line 96:		Line 96:
	</syntaxhighlight>		</syntaxhighlight>

	The pi parameter indicates which ~~Playerlnfo~~ structure is to have its attributes changed. The Tag items indicate the attributes and their new values. If the change is made successfully, then TRUE is returned. FALSE indicates failure. In the fragment above, a wake-up time is		The pi parameter indicates which PlayerInfo structure is to have its attributes changed. The Tag items indicate the attributes and their new values. If the change is made successfully, then TRUE is returned. FALSE indicates failure. In the fragment above, a wake-up time is
	requested using the ~~PLAYER_A1armTime~~ tag. Also, the calling task indicates to the Conductor that it is ready by using the PLAYER_Ready tag (more on this below).		requested using the PLAYER_AlarmTime tag. Also, the calling task indicates to the Conductor that it is ready by using the PLAYER_Ready tag (more on this below).

	At this point, the call to Wait(1UL << midiSignal) causes the task to sleep until time = 1000 ticks.		At this point, the call to Wait(1UL << midiSignal) causes the task to sleep until time = 1000 ticks.
Line 186:		Line 186:
	It is the job of the Conductor to act as middleman between the Amiga's timing hardware and client tasks represented by PlayerInfo structures. Each Conductor keeps track of:		It is the job of the Conductor to act as middleman between the Amiga's timing hardware and client tasks represented by PlayerInfo structures. Each Conductor keeps track of:
	* an Exec list of all its client players		* an Exec list of all its client players
	* the state of the conductor (i.e. running, stopped, paused, locating)		* the state of the conductor (i.e. running, stopped, paused, locating – see below)
	* what time it is relative to start time		* what time it is relative to start time
	* whether the Conductor is using the Amiga’s internal hardware for its timing pulses or an external source		* whether the Conductor is using the Amiga’s internal hardware for its timing pulses or an external source
Line 193:		Line 193:

	<syntaxhighlight>		<syntaxhighlight>
	int32 res = IRealTime->SetConductorState(struct ~~Playerlnfo~~ *pi, int32 newstate, int32 ti);		int32 res = IRealTime->SetConductorState(struct PlayerInfo *pi, int32 newstate, int32 ti);
	</syntaxhighlight>		</syntaxhighlight>

Line 202:		Line 202:
	\| CLOCKSTATE_PAUSED \|\| To the RealTime Library, this is exactly the same as stopped. This is provided as a convenience to those applications that wish to make a distinction between the two.		\| CLOCKSTATE_PAUSED \|\| To the RealTime Library, this is exactly the same as stopped. This is provided as a convenience to those applications that wish to make a distinction between the two.
	\|-		\|-
	\| CLOCKSTATE_RUNNING \|\| The clock is running and time pulses are being distributed to any client applications (~~Playerlnfos~~) that are ready.		\| CLOCKSTATE_RUNNING \|\| The clock is running and time pulses are being distributed to any client applications (PlayerInfos) that are ready.
	\|-		\|-
	\| CLOCKSTATE_LOCATE \|\| This is the same as running with one exception: the clock ~~docs~~ not actually start until ''all'' client applications have indicated that they are ready by setting the PLAYER_Ready attribute of their PlayerInfo to TRUE. This allows applications that cannot start immediately to set up before timing pulses actually begin.		\| CLOCKSTATE_LOCATE \|\| This is the same as running with one exception: the clock does not actually start until ''all'' client applications have indicated that they are ready by setting the PLAYER_Ready attribute of their PlayerInfo to TRUE. This allows applications that cannot start immediately to set up before timing pulses actually begin.
	\|}		\|}

	The difference between locating and running requires some explanation. Each ~~Playerlnfo~~ has a "ready bit" which is used to tell the RealTime Library that the player is ready to receive ticks. This bit is reset each time the library relocates the clock to a new time.		The difference between locating and running requires some explanation. Each PlayerInfo has a "ready bit" which is used to tell the RealTime Library that the player is ready to receive ticks. This bit is reset each time the library relocates the clock to a new time.

	The reason for the ready bit is that some applications need to find the appropriate location in the multimedia sequence or score before they can start playing at the new location. In some cases this can take a considerable amount of time. Hence, CLOCKSTATE__LOCATE is used with the ready bit to allow all players that are sharing a timing context to be synchronized together.		The reason for the ready bit is that some applications need to find the appropriate location in the multimedia sequence or score before they can start playing at the new location. In some cases this can take a considerable amount of time. Hence, CLOCKSTATE__LOCATE is used with the ready bit to allow all players that are sharing a timing context to be synchronized together.

	Players can set the state of their ready bit by using the PLAYER_Ready tag attribute either when the ~~Playerlnfo~~ is created with CreatePlayer() or later with SetPlayerAttrs(). See the first code fragment above for an example of this.		Players can set the state of their ready bit by using the PLAYER_Ready tag attribute either when the PlayerInfo is created with CreatePlayer() or later with SetPlayerAttrs(). See the first code fragment above for an example of this.