OLA Merging Algorithms - Revision history

Peternewman: Add migrated template

2018-06-01T02:19:19Z

Add migrated template

66.92.11.32 at 22:49, 20 February 2010

2010-02-20T22:49:08Z

Nomis52: /* Use Cases */

2010-01-06T18:20:15Z

‎Use Cases

Nomis52: /* Case 5: Priority Escalation */

2010-01-06T18:18:31Z

‎Case 5: Priority Escalation

Nomis52 at 18:12, 6 January 2010

2010-01-06T18:12:46Z

Nomis52 at 18:07, 6 January 2010

2010-01-06T18:07:58Z

Nomis52 at 17:45, 6 January 2010

2010-01-06T17:45:28Z

Nomis52 at 17:37, 6 January 2010

2010-01-06T17:37:12Z

Nomis52 at 06:49, 6 January 2010

2010-01-06T06:49:42Z

Nomis52: Created page with 'This document outlines a draft proposal for multi-source merging in OLA. Please add any discussion on the talk page (remember to include author tags) == Problem Definition == …'

2010-01-06T06:42:00Z

Created page with 'This document outlines a draft proposal for multi-source merging in OLA. Please add any discussion on the talk page (remember to include author tags) == Problem Definition == …'

New page

This document outlines a draft proposal for multi-source merging in OLA. Please add any discussion on the talk page (remember to include author tags)

== Problem Definition ==

The current version of OLA has two merge modes, [[HTP]] & [[LTP]]. This doesn't allow for priority based merging of multiple [[DMX]] sources and in particular, doesn't work well with automated lights.

Ideally a user could configure two input ports to be bound to the same universe, and set the priorities of the ports such that data on one is preferred over another. This can be used to implement backup controllers.

A separate but related problem is that some devices (such as the [[E1.31]] device) support a priority field when sending [[DMX]] data. These fields should be customizable.

The protocols known to support priorities are:
* [[E1.31]]
* [[ETCNet2]] (no OLA plugin)

== Proposal ==

From the [[E1.31]] standard, we define a ''source priority'' which is an integer in the range 0 to 200 with 0 the lowest priority and 200 the highest. The default priority is 100.

Each universe will have an ''active priority'' which is the priority that data is being handled for. Data received with a lower priority will be ignored, while data received with a higher priority will raise the universe's ''active priority'' to match that of the new data.

=== Input ports ===

Input ports will be separated into two types, those that support priorities and those that don't.

Ports that support priorities will offer two modes, ''inherit'' and ''override''. ''Inherit'' mode will use the priority provided by the device/protocol. ''Override'' mode will allow the user to set a priority.

Ports that don't support priorities will allow the user to specify the priority, defaulting to 100.

=== Output ports ===

Output ports that support priorities will again provide ''inherit'' and ''override'' modes. ''Inherit'' mode will use the universe's ''active priority'', ports operating in ''override'' mode will allow the user to specific a priority.

Output ports that don't support priorities won't change.

=== Source Clients ===

Source clients will be able to set a source priority when sending DMX data, this will default to 100.

=== Sink Clients ===

No changes required. We may provide the ''active priority'' in the data packet if required.

=== Resolution of Equal Priority Data ===

Universes will offer a choice of [[HTP]] and [[LTP]] merge modes for when data is received from multiple ports with the same priority.

=== Data Timeouts ===

When a data source doesn't receive data for a specified interval (known as the ''timeout interval'') it's considered disconnected. At this point the source is removed from the list of available sources and the universe's ''active priority'' may reduce. Different ports may have different '''timeout intervals'''.

== Use Cases ==

Consider the following

* Input port A, supports priorities, operating in inherit mode.
* Input port B, doesn't support priorities, manually set to 120
* Source client without a priority (defaults to 100)
* Output port X , doesn't support priorities
* Output port Y, supports priorities

All ports are bound to the same universe. The cases described below are sequential (the events described in Case 2 assume the events of Case 1 have already occurred)

=== Case 1: No Merge ===

No data is received from either input port, and the source client sends data. The ''active priority' is 100. Output Port X sends the data, Output Port Y sends the data with priority 100.

=== Case 2: Simple Merge ===

Data is now also received on port B. The new ''active priority'' is 120. Output Port X sends the data from Port B, Output Port Y sends the data from Port B with priority 120.

=== Case 3: Another Simple Merge ===

Continuing on from Case 2, data is received on port A with a priority of 20. The ''active priority'' is still 120 so this data is discarded. Output Port X continues to sends the data from Port B, Output Port Y continues to send the data from Port B with priority 120.

=== Case 4: Conflict Merge ===

New data is received on Port A with a priority of 120. With two data sources of the same priority, the merge mode of the universe kicks in. The data from ports A and B is either [[HTP]] or [[LTP]] merged depending on the universe setting. Port B continues to send with a priority of 120.

=== Case 5: Priority Escalation ===

New data is received on Port A with a priority of 180. The new ''active priority'' is 180 and the conflict merge stops. Output Port X sends the data from Port A, Output Port Y sends the data from Port A with priority 180.

=== Case 6: Overriding the Output Port Priority ===

The user changes the mode of Port Y from ''inherit'' to ''override'' and sets a value of 130. Output Port X continues to send the data from Port A, Output Port Y sends the data from Port A but with a priority of 130.

=== Case 7: Source Removal ===

Port A stops receiving data and is considered disconnected. The ''active priority'' drops to 120 and both output ports use the data from Port B. Port Y continues to send a priority of 130 because it's operating in ''override'' mode.

== Further Information ==

* [http://www.etcconnect.com/Community/wikis/products/etcnet2-products.aspx ETCNet2 Information]
* [[E1.31]] specification (purchase required)

← Older revision		Revision as of 02:19, 1 June 2018
Line 1:		Line 1:
		+	{{PageMigrated\|url=https://www.openlighting.org/ola/advanced-topics/ola-merging-algorithms/}}
		+
	This document outlines the multi-source merging functionality in OLA.		This document outlines the multi-source merging functionality in OLA.

@@ Line 95: / Line 95: @@
 The user changes the mode of Port Y from ''inherit'' to ''override'' and sets a value of 130. Output port X continues to send the data from port A, output port Y sends the data from port A but with a priority of 130.
 === Case 7: Source Removal ===
 Port A stops receiving data and is considered disconnected. The ''active priority'' drops to 120 and both output ports use the data from port B. Port Y continues to send a priority of 130 because it's operating in ''override'' mode.
 == Further Information ==

← Older revision		Revision as of 18:18, 6 January 2010
Line 89:		Line 89:

	New data is received on Port A with a priority of 180. The new ''active priority'' is 180 and the conflict merge stops. Output port X sends the data from port A, output port Y sends the data from port A with priority 180.		New data is received on Port A with a priority of 180. The new ''active priority'' is 180 and the conflict merge stops. Output port X sends the data from port A, output port Y sends the data from port A with priority 180.
		+
		+	[[File:ola-merge-case5.gif\|center]]

	=== Case 6: Overriding the Output Port Priority ===		=== Case 6: Overriding the Output Port Priority ===

@@ Line 78: / Line 78: @@
 Continuing on from Case 2, data is received on port A with a priority of 20. The ''active priority'' is still 120 so this data is discarded. Output port X continues to sends the data from port B, output port Y continues to send the data from port B with priority 120.
-[[File:Ola-merge-case3.gif]]
+[[File:Ola-merge-case3.gif|center]]
 === Case 4: Conflict Merge ===
 New data is received on port A with a priority of 120. With two data sources of the same priority, the merge mode setting of the universe kicks in and the data from ports A and B is [[HTP]] or [[LTP]] merged depending on the universe setting. Port B continues to send with a priority of 120.
 === Case 5: Priority Escalation ===

← Older revision		Revision as of 18:07, 6 January 2010
Line 77:		Line 77:

	Continuing on from Case 2, data is received on port A with a priority of 20. The ''active priority'' is still 120 so this data is discarded. Output port X continues to sends the data from port B, output port Y continues to send the data from port B with priority 120.		Continuing on from Case 2, data is received on port A with a priority of 20. The ''active priority'' is still 120 so this data is discarded. Output port X continues to sends the data from port B, output port Y continues to send the data from port B with priority 120.
		+
		+	[[File:Ola-merge-case3.gif]]

	=== Case 4: Conflict Merge ===		=== Case 4: Conflict Merge ===

@@ Line 1: / Line 1: @@
-This document outlines a draft proposal for multi-source merging in OLA. Please add any discussion on the talk page (remember to include author tags)
+This document outlines the multi-source merging functionality in OLA.
 == Problem Definition ==
-The current version of OLA has two merge modes, [[HTP]] & [[LTP]]. This doesn't allow for priority based merging of multiple [[DMX]] sources and in particular, doesn't work well with automated lights.
+The old version of OLA had two merge modes, [[HTP]] & [[LTP]]. This didn't allow for priority based merging of multiple [[DMX]] sources and in particular, didn't work well with automated lights.
-Ideally a user could configure two input ports to be bound to the same universe, and set the priorities of the ports such that data on one is preferred over another. This can be used to implement backup controllers.
+A separate but related problem what that some devices (such as the [[E1.31]] device) support a priority field when sending [[DMX]] data. These fields should be customizable.
 The protocols known to support priorities are:

← Older revision		Revision as of 17:45, 6 January 2010
Line 71:		Line 71:

	Data is now also received on port B. The new ''active priority'' is 120. Output port X sends the data from port B, output port Y sends the data from port B with priority 120.		Data is now also received on port B. The new ''active priority'' is 120. Output port X sends the data from port B, output port Y sends the data from port B with priority 120.
		+
		+	[[File:ola-merge-case2.gif\|center]]

	=== Case 3: Another Simple Merge ===		=== Case 3: Another Simple Merge ===

← Older revision		Revision as of 17:37, 6 January 2010
Line 65:		Line 65:

	No data is received from either input port and the source client sends data. The ''active priority'' is 100. Output port X sends the data, output port Y sends the data with priority 100.		No data is received from either input port and the source client sends data. The ''active priority'' is 100. Output port X sends the data, output port Y sends the data with priority 100.
		+
		+	[[File:ola-merge-case-1.gif\|center]]

	=== Case 2: Simple Merge ===		=== Case 2: Simple Merge ===

@@ Line 29: / Line 29: @@
 === Output ports ===
-Output ports that support priorities will again provide ''inherit'' and ''override'' modes. ''Inherit'' mode will use the universe's ''active priority'', ports operating in ''override'' mode will allow the user to specific a priority.
+Output ports that support priorities will again provide ''inherit'' and ''override'' modes. ''Inherit'' mode will use the universe's ''active priority'', ports operating in ''override'' mode will allow the user to specify a priority.
 Output ports that don't support priorities won't change.
@@ Line 39: / Line 39: @@
 === Sink Clients ===
-No changes required. We may provide the ''active priority'' in the data packet if required.
+No changes required. We may provide the universe's ''active priority'' in the data packet if required.
 === Resolution of Equal Priority Data ===
@@ Line 47: / Line 47: @@
 === Data Timeouts ===
-When a data source doesn't receive data for a specified interval (known as the ''timeout interval'') it's considered disconnected. At this point the source is removed from the list of available sources and the universe's ''active priority'' may reduce. Different ports may have different '''timeout intervals'''.
+When a data source doesn't receive data for a specified interval (known as the ''timeout interval'') it's considered disconnected. At this point the source is removed from the list of available sources and the universe's ''active priority'' may reduce. Different ports may have different ''timeout intervals''.
@@ Line 57: / Line 57: @@
 * Input port B, doesn't support priorities, manually set to 120
 * Source client without a priority (defaults to 100)
-* Output port X , doesn't support priorities
+* Output port X, doesn't support priorities
 * Output port Y, supports priorities
@@ Line 64: / Line 64: @@
 === Case 1: No Merge ===
-No data is received from either input port, and the source client sends data. The ''active priority' is 100. Output Port X sends the data, Output Port Y sends the data with priority 100.
+No data is received from either input port and the source client sends data. The ''active priority'' is 100. Output port X sends the data, output port Y sends the data with priority 100.
 === Case 2: Simple Merge ===
-Data is now also received on port B. The new ''active priority'' is 120. Output Port X sends the data from Port B, Output Port Y sends the data from Port B with priority 120.
+Data is now also received on port B. The new ''active priority'' is 120. Output port X sends the data from port B, output port Y sends the data from port B with priority 120.
 === Case 3:  Another Simple Merge ===
-Continuing on from Case 2, data is received on port A with a priority of 20. The ''active priority'' is still 120 so this data is discarded. Output Port X continues to sends the data from Port B, Output Port Y continues to send the data from Port B with priority 120.
+Continuing on from Case 2, data is received on port A with a priority of 20. The ''active priority'' is still 120 so this data is discarded. Output port X continues to sends the data from port B, output port Y continues to send the data from port B with priority 120.
 === Case 4: Conflict Merge ===
-New data is received on Port A with a priority of 120. With two data sources of the same priority,  the merge mode of the universe kicks in. The data from ports A and B is either [[HTP]] or [[LTP]] merged depending on the universe setting. Port B continues to send with a priority of 120.
+New data is received on port A with a priority of 120. With two data sources of the same priority, the merge mode setting of the universe kicks in and the data from ports A and B is [[HTP]] or [[LTP]] merged depending on the universe setting. Port B continues to send with a priority of 120.
 === Case 5: Priority Escalation ===
-New data is received on Port A with a priority of 180. The new ''active priority'' is 180 and the conflict merge stops. Output Port X sends the data from Port A, Output Port Y sends the data from Port A with priority 180.
+New data is received on Port A with a priority of 180. The new ''active priority'' is 180 and the conflict merge stops. Output port X sends the data from port A, output port Y sends the data from port A with priority 180.
 === Case 6: Overriding the Output Port Priority ===
-The user changes the mode of Port Y from ''inherit'' to ''override'' and sets a value of 130. Output Port X continues to send the data from Port A, Output Port Y sends the data from Port A but with a priority of 130.
+The user changes the mode of Port Y from ''inherit'' to ''override'' and sets a value of 130. Output port X continues to send the data from port A, output port Y sends the data from port A but with a priority of 130.
 === Case 7: Source Removal ===
-Port A stops receiving data and is considered disconnected. The ''active priority'' drops to 120 and both output ports use the data from Port B. Port Y continues to send a priority of 130 because it's operating in ''override'' mode.
+Port A stops receiving data and is considered disconnected. The ''active priority'' drops to 120 and both output ports use the data from port B. Port Y continues to send a priority of 130 because it's operating in ''override'' mode.
 == Further Information ==