GB2386983A - Touch sensor network for data processing apparatus - Google Patents

Abstract

A network of client devices has touch sensitive controls with an enabled state such that they can detect a touch and an quiescent state in which they do not detect a touch. The network is linked to a host device which processes data as indicated by the controls on the client devices. The host device is set up to start a global scan of the network, comprising a predetermined sequence of local scans, consecutive local scans being started by client to client communications. The local scans are set up to scan the touch sensors of the client devices, in which the sensors are changed from a quiescent state to an enabled state. The enabled period of each sensor in a local scan could be at least partially non-coincident with the enabled periods of the other sensors. Also the global scan could be configured such that the local scans do not overlap in time. The apparatus could be an audio mixing desk.

Description

1 2386983

DATA NETWORK

This invention relates to data networks.

Data networks are used to communicate between data processing devices. Some s of these devices may carry out processing tasks in their own right, while others may be "dumb" terminals, acting only to provide input data to another device or to provide an output of data generated by another device.

The present invention is applicable to data networks carrying audio, video or any other type of data. For this explanation, however, an example of an audio processing lo network will be described.

In an audio processing network, it has been proposed that a host computer carries out audio processing operations on one or more input digital audio signals to generate one or more output audio signals. The detailed operations carried out by the host computer are defined by user controls forming part of client data processing terminals connected to 5 the host computer by a data network. The user controls define audio processing parameters such as gain, frequency and the like. Using this arrangement, only control (parameter) data needs to be transmitted from the client terminals to the host computer; the audio data itself, which is generally represents a very much greater throughput of data, is handled only at the host computer.

to So, to adjust an audio processing parameter, the user moves a control at a client terminal. The client terminal detects the change and transmits data representing the adjustment - for example, the new parameter value or the change in parameter value - to the host computer via the data network. The host computer then implements the change at the next available opportunity.

25 Similarly, some output parameter data may need to be displayed to the user. For example, the level of an audio signal at a particular place in the audio processing arrangement may need to be displayed in the form of a bargraph. To achieve this, parameter data needs to be transmitted from the host computer to the client terminals via the data network.

30 In some systems of this general type, it is desirable to detect when a user is touching a user control, even if the user is not actually moving the control. This could be useful just to obtain advance warning of a control which is about to be adjusted, or to detect where a user (e.g. a security guard on patrol) is located amongst a distributed

network of client devices, but in the particular example to be described here, touch sensitive controls are needed in an automated audio mixing system.

Audio mixing systems typically employ user controls known as faders.

Originally, these were simply linear analogue potentiometers with a moving "slide)', but 5 in digital audio processing systems they may be linearly sliding position encoders, providing a numerical output indicative of the slider's position, which in turn is ultimately used to control some aspect of the digital audio processing, such as a gain setting. The fader also has the feature that the faders slider provides a clear visual indication to the user of its current setting.

0 In an automated mixing system, the faders are motorised. Thus allows the fader slider's position, as well as the underlying gain or other parameter value, to be controlled by an automation system. Many automation systems allow the user to override the stored automated control settings, possibly overwriting new automation settings. However, it is then important that the motor system does not fight against the user trying to move the 5 slider. To prevent this, it is necessary to detect when the user is touching the slider and to disable the motor system in response to such a detection.

The touch detectors are typically capacitive detectors, that is to say, they detect the change in capacitance caused by a user's finger touching or being very close to an electrode on the slider. A recognised problem here is that if the same user touches many 20 sliders at the same time, the change in capacitance detected at each individual slider is correspondingly reduced and becomes harder to detect reliably. To overcome this problem, GB-A-2 293 242 proposes a scanning arrangement whereby only one touch detector is enabled at once.

This invention provides data processing apparatus comprising: 25 two or more client devices, each client device having one or more user controls, each user control having an associated touch sensor having an enabled state in which it is arranged to detect a touch by a user and a quiescent state in which it is arranged not to detect such a touch; a host device operable to control data processing operations in dependence upon a 30 status of the one or more user controls; a network for providing a data communications path connecting the host device and the two or more client devices;

in which each client device is operable to perform a local scan in which one or more touch sensors at that client device are changed from the quiescent state to the enabled state for a respective enabled period; and in which the host is operable to configure a global scan comprising a 5 predetermined sequence of local scans, consecutive local scans in the predetermined sequence being initiated by client-to-client data communications.

The invention recognises that the arrangement of GB-A-2 293 242 works well with a set of touch detectors associated with a single control apparatus (e.g. a mixing desk) because the scanning arrangement can be implemented as very simple logic (a shift lo register or the like) within that one control apparatus. However, if the user controls are distributed across different devices in a networked arrangement, the situation becomes more complicated. In this case, it is undesirable that each networked device should scan its own user controls autonomously, as this could lead to poor detection if the user happens to touch controls on different networked devices and which happen to be enabled 5 for touch detection at the same time.

However, any arrangement has to take into account the need for a very rapid touch detection across all of the user controls, regardless of how many network devices accommodate those user controls. If the detection is too slow, there will be a period during which the control's motor system fights the user. However, network 20 communications, especially where the system is under the control of a host device, often do not lend themselves to such rapid communications between devices.

The invention addresses this problem by providing a predetermined scanning order of the touch detectors associated with user controls across the whole system.

Preferably, this involves a scan of all the touch sensitive user controls associated with a 2s particular client device, followed by a scan of all of the touch sensitive user controls associated with a next client device, and so on. The overall scan is initiated periodically by receipt of a network clock message at the client having the first touch detector in the scanning order, but thereafter, whenever the scanning order passes from a touch detector on one client to a touch detector on another client, a client to client message (for speed) is 30 sent.

Further respective aspects and features of the invention are defined in the appended claims.

Embodiments of the invention will now be described with reference to the accompanying drawings, throughout which like parts are referred to by like references, and in which: Figure 1 is a schematic block diagram of an audio control network; 5 Figure 2 is a schematic diagram illustrating the layered structure a basic TCP/IP protocol local networking system; Figure 3 schematically illustrates the structure of a UDP data packet; Figure 4 schematically illustrates the structure of a TCP data packet; Figure 5 schematically illustrates how a data packet evolves as it passes o through the TCP/IP layers during construction and prior to transmission, Figure 6 schematically illustrates the structure of a control message, a client update packet and a UDP datagram according to an embodiment of the invention, Figure 7A schematically illustrates client-side processing following user adjustment of a rotary encoder setting; 5 Figure 7B schematically illustrates host-side data processing in response to the client-side processing of Figure 8A; Figure 8 is a flow chart illustrating a sequence of events occurring within a network clock period; Figure 9 is a schematic block diagram illustrating a distributed audio network 20 comprising three fader control panels; Figure 10 is a flow diagram illustrating a sequence of events occurring during a global scan of the fader control panels of Figure 9; Figure 11 is a flow chart illustrating how "adjustment timestamps" are used to provide a substantially consistent response latency in a case where adjustment of a user 25 control at the client results in performance of an audio data processing task by the host; Figure 12A schematically illustrates client- side processing following user adjustment of a capacitive fader knob; Figure 12B schematically illustrates host-side data processing in response to the client-side processing of Figure 12A; 30 Figure 13 schematically illustrates how a consistent response latency is achieved for a client-side user interface adjustment following from a client-side button-press operation; Figure 14A schematically illustrates client-side processing following a button press operation,

Figure 14B schematically illustrates host-side data processing in response to the client-side processing of Figure 14A.

Figure 1 is a schematic block diagram of an audio control network 100 according to an embodiment of the invention. The audio control network comprises a host 110, a s first Ethernet hub 120, a second Ethernet hub 130, a first control surface 140, a second control surface 150, a network clock node 160 (optionally included), a first analogue-to digital converter (ADC) 170A, a second ADC 170B and a digital-to-analogue converter (DAC) 170C.

The control surfaces 140, 150, the network clock node 160 and the ADC lo and DAC converters 170A, B. C are connected to the host 110 via Ethernet. Ethernet is a local area network (LAN) technology, which uses a simple or branching bus-like connection line. The transmission medium in this Ethernet network is formed from one or more continuous lines of cable linked by hubs 120, 130. Network devices 140, 150, c 160, 170A, B,C are connected to the cable and they compete for network access using a 15 Carrier Sensing Multiple Access with Collision Detection (CSMA/CD) protocol.

According to the CSMA/CD protocol, all client devices monitor the transmission medium and wait until the transmission line is available before transmitting any messages. If two network nodes such as the first and second control surfaces 140, 150 try to transmit messages at the same time, a collision occurs. The client devices then stop, wait for a 20 random time interval and attempt to transmit again.

Standard Ethernet systems known as 1 OBASE-T systems provide -

transmission speeds up to 10 Mega bits per second (Mbps) whereas socalled "Fast Ethernet" (or lOOBASE-T) systems provide transmission speeds of up to 100 Mbps. This embodiment of the invention uses Fast Ethernet. However further variants such as 25 Gigabit Ethernet may also be used.

The host 110 manages the hardware control surfaces 140, 150 and the ADC/DAC units 1 70A, B,C via packet data communications over Fast Ethernet. In this particular embodiment the host is a Sonoma_ Windows_ PC.

The audio control network 100 manages routing of audio control data only.

30 The audio data is dealt with by separate means and is not transmitted via the Fast Ethernet network. It is more efficient to transmit the audio data separately from the control data and by other means. In this embodiment the host performs audio processing operations such as gain control, trimming and equalisation based on status values of user controls on

the client panels of the control network. In alternative embodiments the host could simply collate and pass control data to a separate audio processing device (not shown).

The first hub 120 is a Fast Ethernet hub located in a machines room and this connects the ADC/DAC units 170A,B,C to the host 110. The ADC units 170A and 5 170B both have 8-channel ADCs, each channel having 8-bit audio controls known as gain controls and trim controls. The ADC/DAC units are connected to the audio control network to, facilitate remote control of gain settings and remote monitoring of input overload status. Liquid crystal displays (LCDs) on the front panels of these units provide a user interface and give the operator an indication of current audio processing parameter 0 settings. The DAC unit 170C comprises 8-channel DACs and has rotary encoders on the front panels identical to those provided on the ADC units.

The second hub 130 is also a Fast Ethernet hub but this is located in a studio rather than in the machines room and it serves to connect the control surfaces 140, 150 and the network clock node 160 to the host 110. The first control surface 140 is a 5 "fader surface" comprising 8 motorised faders, audio channel select switches, solo switches and cut switches. The fader surface is additionally provided with graphic LCD channel displays, that indicate to the user which audio channel is currently being controlled, and bus assign controls. In this particular embodiment the second control surface 150 comprises two rotary encoders per channel and four graphic LCD bus assign 20 controls. In alternative embodiments further control surfaces may be provided in the local audio network, for example, a "channel strip control surface" having equalization and dynamics controls or a recorder control interface could further be provided.

Each of the client devices has input controls and output devices. An input control is defined to be a user-adjustable control such as a switch, a knob, or a fader, that 25 provides a means for user input into the audio control system. An output device, on the other hand, is a device that displays audio control system information to the user.

Examples of output controls are LEDs, a visual display unit, the position of a motorised fader along a sliding scale or an ADC gain control.

The audio control network communicates information regarding the 30 current status or setting of each input control and output device between nodes of the local network via packet data communications. Information corresponding to a change in or update to the status of a single input control or output device is communicated via a data transmission known as a "control message". One or more control messages are grouped together with other messages to form a Client Update Packet (CUP). An input

client update packet (I/P CUP) is transmitted from client to host whereas an output client update packet (O/P CUP) is transmitted from host to client. Each CUP is transmitted within a single UDP/IP message. An ordered sequence of alternating host-to-client and client-to-host transmissions is initiated by each network clock message. User datagram 5 protocol (UDP) and internet protocol (IP) are network communication protocols and they will be discussed further below.

The 1 OOMbps UDP/IP/Fast Ethernet link provides sufficient bandwidth to transfer all output control settings for about thirty fader panels in a single O.Ols network clock period. Since audio control networks will typically be smaller than this there should lo be enough time to transmit all the client update packets required in one network clock period (if not, the network clock period could be extended).

The network clock node 160, which is optionally provided, is responsible for network synchronization. In this embodiment the network clock is a client device, although in alternative embodiments the host could serve the function of the network 5 clock. The network clock node broadcasts network clock messages throughout the network every network clock period (PNC), thus providing a timing framework for network communications. In this particular embodiment the network clock period is PNC = 0.01s. This value of PNC was chosen because it corresponds to a quarter of a 0.04s video frame. Thus the network clock could be derived from any incoming 20 synchronization reference such as a timecode clock or an audio sample clock.

Network clock messages, which are broadcast over internet protocol (IP) provide the finest timing resolution in the audio control system. Each network clock message includes a data field, which contains flags to assert other network synchronization

functions. Examples of these data flags and the period with which the flag is set (flag 25 value equal to 1 rather than 0) are given in the Table 1 below.

Table 1

Period Description and remarks

-.125s LED flash sync: each sixteenth message is replaced with a LED flash phase sync message, as described below.

2s LED Dash phase sync: replaces each sixteenth LED flash synchronization message Local timestamp timer sync: timestamp timers in network

- 3s devices are periodically re-synchronised to ensure corect operation of message timestamping system.

As described above, a designated network node generates network clock messages. In this embodiment the client node 160 is used as the network clock rather than the host node 110 because the host uses the proprietary Microsoft Windows NT s software environment. Windows NT is a multithreaded software environment and there are known difficulties with achieving timing control in some multithreaded environments.

In alternative embodiments, instead of a client network node, the Ethernet port on a "Sonoma2" card in the host 110 is used to generate suitable network clock messages via a low-level connection to the Sonoma2 hardware.

0 The operating system installed on the client devices is the ThreadX_ operating system proprietary to Express Logic and distributed under licence by NetSilicon in their Net+Works_ development package. Each client device comprises a NetSilicon Net+ARM_ chip with an ARM7_ core. Net+ARM_ is a trade mark of ARM Ltd., licensed exclusively to NetSilicon.

s The network clock generation functionality is part of a common network protocol code used by all of the client nodes on the network and consequently any designated client can generate the network clock signal. To determine which client should generate network clock signals an arbitration scheme is implemented by the audio network control system using an algorithm as described below.

20 On timeout, after receiving no network clock signal a client starts generating network clock messages. These network clock messages feature the IP address of the corresponding client in the IP header of the data message. The client ignores network clock messages with a higher source IP address than itself. If however, the client receives a network clock message with a source IP address lower than itself then it ceases generating its own network clock messages. Accordingly the client with the lowest IP address will become the designated network clock node.

If any client is found to be generating network clock signals from a valid external synchronization source (such as a universal synchronizer deriving clocks from video synchronization) then that client will be selected as the network clock generator in 30 preference to the client with the lowest IP address.

The network communication protocols used in embodiments of the invention will now be described. Although the protocols themselves are known, the structure of the control messages and client update packets is not.

Figure 2 is a schematic diagram showing a layered representation of a 5 basic TCP/IP protocol as used in the audio control local network. The layered architecture comprises an application layer 210, a transport layer 220, an internet protocol (IP) layer 230 and a network access layer 240. The application layer 210 supports network applications and provides an interface to a local operating environment. The transport layer 220 performs error checking and acknowledgement and serves as an interface for 0 network applications. The IP layer 230 provides IP addresses for local network nodes thus allowing for navigation of the local network.

Data, such as client update packets, produced in the application layer 210 is first passed to the transport layer 220 to either of the two transport layer protocols,;-

transmission control protocol (TCP) or user datagrarn protocol (UDP).

15 TCP is a connection-oriented protocol, which means that before any data is transferred between network nodes, the sending and receiving devices must co-operate in the establishment of a bi-directional communication channel. Subsequently, each package of data sent across the local network receives an acknowledgement and the sending device records status information to ensure that each data package is received 20 without errors.

In contrast, UDP is a connectionless protocol, which means that a one-way data packet is sent by the sending device without notifying the receiving device that the data is en route. On receipt of each data packet, the receiving device does not return status information to the sending device. Although TCP, being a connection-oriented 25 protocol, is more reliable than UDP, the additional error checking and flow control performed by TCP means that it is slower than UDP. A data package created at the transport layer 220, which encapsulates an application layer message, is known as a "datagram" if it comes from the transport layer's UDP protocol but is known as a "segment" if it comes from the transport layer's TCP protocol.

30 Having passed through the transport layer 220, the data package passes to an IP module 232 in the IP layer 230 where the internet protocol provides logical addressing information and packages the transport layer data to form datagrams. The IP protocol provides for transmission of datagrams from one local network node to another, if necessary, via intermediate routers. The IP delivery service offers no guarantee of

delivery so data packets can potentially be lost, duplicated, delayed or delivered out of order. However such errors typically only arise when the underlying network fails or when buffers at the receiving device are full. The IP layer 230 must also insert a "physical" network address of the message destination. This physical addressing is done 5 by the ARP/RARP module 234. Address Resolution Protocol (ARP) translates IP addresses to physical addresses whereas Reverse Address Resolution Protocol (RARP) translates physical addresses to IP addresses.

The IP datagrams form the IP layer 230 are passed to the network access layer 240 where they are supplied to software components that interface with the physical lo network. The network access layer 240 converts each IP datagram into one or more data "frames". In the case of a local area network (LAN) such as the Ethernet network used in the embodiment of Figure 1, each data frame may contain address information derived from lookup tables in the IP layer. Finally the data frames formed in the network access layer 240 are converted to a bit stream and transmitted over the local network to the 5 appropriate receiving devices.

Figure 3 schematically illustrates the structure of a UDP datagram comprising a header 250 and a data payload 260. The datagram header 250 comprises four 16-bit fields: a source port field 252; a destination port field 254; a length field 256

and a check sum field 258. The source port field 252 typically holds the appropriate UDP

20 port number of the sending device. The source port field value, where provided, is used

as a return address by the receiving device. Provision of a valid source port field is

optional. The destination port field 254 specifies the UDP port address on the receiving

device to which the datagram should be delivered. The length field 256 specifies the total

length (header plus payload) in octets of the UDP datagram. The checksum field 258 is

25 used to establish whether the datagram was corrupted during transmission. The data payload 260 is variable in length. UDP provides a means of transmitting messages of up to 64 Kbytes (the maximum standard packet size permitted by IP) in size. The UDP header 250 does not include the source or destination IP addresses, only the UDP port addresses, however the checksum data includes destination IP address information that 30 allows a receiving device to determine whether a UDP datagram has been incorrectly delivered. Figure 4 schematically illustrates the structure of a TOP segment header 350 and a data payload 360. A 16-bit source port field 310 specifies a number assigned to

an application on a source device. A 16-bit destination port field 312 specifies a port

number assigned to an application on a destination device. A 32-bit sequence number field 314 is used to synchronise sequence numbers. If SYN=1 (see description of flags

330A to 330G below) then this field specifies an initial sequence number, otherwise it

specifies the number of the first byte of the current segment. A 32-bit acknowledgement 5 number field 316 specifies the next sequence number that the destination device is

expecting to receive i.e. last byte received +1. A 4-bit data offset field 318, specifies how

long the header is and hence specifies where the data begins. A reserved field 320

contains zeros and is provided to accommodate future developments to TCP.

A series of six control flags 330A to 330F corresponding to URG, ACK, 0 PSH, RST, SYN and FIN respectively communicate information about the data segment.

If URG=1 the segment is urgent so an urgent pointer field 336 is significant. If ACK=1 it

follows that the acknowledgement number field 316 is significant. If PSH=1 the TCP

software must push all of the data sent so far through the pipeline to the application at the destination node. If RST=1 the connection is reset. If SYN=1 the sequence numbers will be synchronized to mark the beginning of a connection. If FIN=1 the source node has no more data to transmit and the connection is closed.

A 16-bit window field 332 defines a range of sequence numbers beyond a

last acknowledged sequence number that the source node is allowed to transmit without further acknowledgement. Accordingly the window parameter is used for flow control.

20 A 16-bit checksum field 334 is used to check the integrity of the current data segment. A

16-bit urgent pointer 336 is used to provide an offset and points to a sequence number that marks the beginning of urgent information. An options field 338 specifies one of a

set of optional settings. A padding zone 340 contains extra zero bits to ensure that the payload data begins on a 32-bit boundary. The data payload 360 contains the data being 25 transmitted with the current segment.

Figure 5 shows how data is packaged at each layer of a TCP/IP protocol stack. As an outgoing transmission passes down through the protocol stack from the application layer 210 to the network access layer 240, each layer appends a header to the data. The application layer 210 produces a message 212 consisting of a data payload 30 212D and a header 212H. This message corresponds to a client update packet (CUP) as described in detail below with reference to Figure 6. The message 212 is passed to the transport layer which encapsulates the application layer message 212 to produce a transport layer segment/datagram 222. Thus the application layer message 212 (payload plus header) becomes the data 222D that is repackaged in the transport layer where a

header 222H is appended. Similarly the transport layer segment/datagram 222 is passed onto the IP layer where it becomes the data payload 236D and a header 236H is appended. The IP layer data packet 236 is passed onto the network access layer where it becomes the data payload 242D and a header 242H is appended to it to form a data frame 5 242. At each protocol layerthe package of data is of a form appropriate to that layer and because each layer performs different functions, the form of the data package is very different at each layer. Note that in an Ethernet network, the data is typically broken down into smaller units in the network access layer 240.

A reverse process occurs at the receiving device as the data packet moves 0 up through the protocol stack from the network access layer 240 to the application layer 21 O. each layer unpacking the appropriate header. The client update packet is retrieved in the application layer.

In the audio control network of Figure 1, the audio data processing is performed under the control of the host. However, in this embodiment the actual audio 5 data is not transported via the Ethernet network because it is more efficient to transport the audio data separately by other means. Only the control system uses the Ethernet network. As outlined above, the audio control network uses internet protocol to assign a unique IP address to each device in the network. In this embodiment the IP addresses are configured automatically by a designated DHCP server using Dynamic Host 20 Configuration Protocol (DHCP). In alternative embodiments the IP addresses are configured manually.

Control communications between client devices such as control surfaces 140, 150 and ADC/DAC converter units 170A, B. C use UDP. UDP is also used for real-

time network synchronization. TCP is implemented on each client device as well as the 25 host device and is used for system diagnostics.

Figure 6 schematically illustrates the structure of a control message, a client update packet and a UDP datagram. In the application layer 210, a plurality control messages and other messages are bundled together in the form of a client update packet (CUP) 400. The CUP 400 comprises: a 4-byte CUP header 410 which acts as a message 30 type identifier and a plurality of control messages 420A, 420B,, 420N. A single client update packet communicates all required changes to the status of the user interface devices (such as rotary encoders, switches and buttons) belonging to a specific client that have occurred within a single network clock period. I/P CUPs containing input control data are sent from client to host whereas O/P CUPs containing output control data are

sent from host to client. In either case CUPs typically contain control messages only for user interface devices whose status has changed in the last network clock period.

However, if the host issues a "send all data" command then the current control values for every input control will be sent in the CUP, regardless of whether the control value has 5 changed in the last network clock period. There is no predetermined upper limit on the number of control messages that can be included in a CUP so the available bandwidth on the network is the main constraint on CUP packet size. Although CUPs are typically transmitted using a single UDP packet, if necessary, they will be fragmented to form multiple UDP packets.

lo Control messages such as the one illustrated in Figure 6 are variablelength messages, each of which communicates the status of a specified input control or output device on a given client. Each control message 300 comprises: a 2-byte control ID field

310 which identifies the input or output device on the given client device to which the control data relates; a flags field 320 containing predetermined flag values; a timestamp

Is field 330 containing a real-time time value used to determine when instructions in the

control message are executed; and a control value field 340 containing the current setting

corresponding to the control ID specified in field 310.

The format of the control value field is dependent upon the value of the

control ID 310. The CUPs are formed in the application layer 210 and when passed down 20 through the TCP/IP protocol stack to the transport layer 220 the CUP forms the UDP datagram payload 440 to which a UDP header 450 is appended.

User controls and user interfaces on each client are numbered: these numbers are defined separately for each client type (fader panel, ADC unit etc.), and are stored locally in firmware by each client. The control ID numbers are assigned sequentially to controls 25 according either to their position on the client device front panel or to a position in the signal path, in the case of audio hardware.

For example a client l corresponding to a fader control surface 140, knows that control 84 is the third fader along; client 3, an identical fader control surface, knows that its control 84 is the third fader along; and client 2, an editor control surface, knows that its 30 control 84 is the record button LED.

The local control number mappings for each client type are also stored in memory of the host device, which maps them to system functionality. The host keeps track of which audio channels are assigned to each user control at any given time. For

example the host knows that:-'client 1 control 84' is the channel 11 fader; 'client 3 control 84' is the channel 3 fader, and 'client 2 control 84' is the record button light.

Mappings between control numbers, control types and data types are held in both the host application, and in the client firmware. Control messages are assembled taking 5 account of the data format required by the particular user control to which the control message relates.

First consider a change to an output control value that must be communicated from host to client.

The host knows that faders require 1 6-bit data: therefore client 3 Control 84 is sent lo 16-bit data. Client 3 also knows that control 84 requires 16-bit data so when the 16-bit data dispatched in a control message by the host 10 is received at client 3, it is written to the fader which automatically resets the fader position in accordance with the data value e.g. the fader moves to half way along the scale on the fader panel.

The host also knows that LEDs require 1-bit data: therefore client 2 control 84 is I s sent 1 -bit data. Client 1 knows that control 84 requires one data bit so when the 1 -bit data dispatched by the host 10 is received at client 2,the data is written to the LED, which lights up.

Next consider a change to an input control value that must be communicated from client to host. Say client 2 knows that its control 84 produces 16-bit data. A user has 20 pushed a fader control knob to a minimum position on the scale, producing a fader control data value of OxOOOO. A corresponding control message is sent to the host 10 as part of a CUP in the next network clock period. The CUP is received by the host 10 shortly afterwards and the host extracts the control message. The host knows that a data value of OxOOOO from Client 2 Control 84 (a control of type 'fader') means that the fader is at 2s minimum travel so the host adjusts audio engine parameters accordingly.

Control IDs are oftwo types: universal control IDs and device specific IDs.

Universal control IDs identify special-function messages, such as administrative communication messages with a central processing unit (CPU) for controlling a client control surface. Universal control IDs are also be used to identify message format 30 extensions for future use. Definitions for these universal control IDs are common across all device types and a range of control ID values are reserved for this purpose as shown in Table 2 below (in which 'x' represents a "don't care" logic value). Control value formats are specific to particular universal control IDs.

Control ID range Function OxFEOO-OxFEFF Special-function messages for device administration and testing.

OxFFOO-OxFFFF Prefixes for future extensions to protocol.

Table 2

Device-specifc Control IDs identify specific hardware controls (e.g. fader 3, or record button LED) on the corresponding network device. Definitions for local control IDs are unique to each control surface type and firmware version. Local control IDs do 5 not use any numbers reserved for universal control IDs. The control value data format is dependent on the type of hardware control (fader, switch etc.) referred to by the corresponding control ID.

The mapping between device-specific control IDs and data formats is held separately in the host software and in the firmware of the client device. Device-specific lo control IDs may not start with the byte value OxFF. However there are a total of 61440 device-specific control IDs in the hexadecimal range OxOOOO to OxEFFF. A unique map of control IDs exists for each device type and version.

A particular type of control device used on the client control panels 140, 150 is a digital rotary encoder. Such rotary encoders provide position information feedback to the host regarding the setting of the user control. The rotary encoders can either be absolute or incremental. Absolute encoders use a different digital word to represent each angular position of the rotary control so that they provide an absolute location. However, incremental encoders only give the current control location relative to another location.

They typically send out one pulse for each given incremental distance of travel and the 20 user adjustment to the incremental rotary encoder knob is quantified by the number of pulses. These rotary encoders typically have contacting or Hall-effect internal switching.

This embodiment uses rotary encoders manufactured by Bourns. The rotary encoder knob may, depending on the application, be surrounded by a ring of Light Emitting Diodes (LEDs) which can be illuminated to act as pointers indicating a current parameter 25 setting.

A single rotary encoder will typically be used to control a number of different audio channels or a number of different audio parameters on a given channel. A channel selector is used so that, at any one time, the rotary encoder is operable to adjust a single parameter such as volume on a single channel. When a given parameter for a given

channel has been set using the rotary encoder, its value is digitally stored in memory (by the host device). The set parameter will continue to operate on the audio channel even once the rotary encoder has been assigned a different channel and/or audio parameter to control. Following a channel or parameter assignment change, the pointer position on the 5 rotary encoder must be reset to the current setting of the parameter under control.

Figure 7A schematically illustrates a data processing sequence initiated by user adjustment of a rotary encoder knob. Note that, in this embodiment, the host device performs audio parameter and channel assignment functions, which map the rotary encoder to a particular variable and audio channel. Following user-adjustment of lo the rotary encoder 512, a position determining circuit 610 processes outputs from the dual potentiometer arrangement 516, 518 in order to provide an indication of new setting of the control knob. A change detection module 620 at the client registers a change to the appropriate audio parameter value and logs the local real-time corresponding to the rotary encoder adjustment. A local real-time clock 630 at the client provides the real- time value.

5 The setting adjustment information is supplied to a message assembler 640 which assembles a control message indicative of the change to the setting of the rotary encoder and of the adjustment timestamp and appends this control message to an input client update packet. Transmission of the input client update packet to the host is initiated by the client on receipt of an output client update packet from the host 20 7B illustrates subsequent data processing operations at the host device. On arrival at the host the client update packet is disassembled and the control messages are queued in a host input buffer 658. When the host's local real-time clock coincides with a time corresponding to the adjustment timestamp plus a predetermined latency period the control message indicative of the adjustment to the rotary encoder is taken from the input :5 buffer 658 and executed by the host. A data selector 660 determines which audio channel and parameter value the rotary encoder was associated with at a time corresponding to the adjustment timestamp. A data adder 670 then translates the change in rotational extent of the rotary encoder to a new parameter value and the appropriate audio data processing is performed by module 680. The time at which the audio data 30 processing takes effect will closely correspond to the control adjustment time plus the predetermined latency period as measured by the local real-time clock 690 in the host device. The synchronization of the devices of the audio control network will be described in more detail below with reference to Figures 1 1 to 14.

Figure 8 provides an overview of a sequence of communications between a client device and the host device, typically occurring in one network clock period. At stage I a network clock message is received. Following receipt of the network clock message, the host determines at stage II whether there have been any changes to output 5 device settings within the last network clock period and assembles control messages indicative of such changes in an output client update packet (O/P CUP). The O/P CUP is stored, awaiting transmission, in a host output buffer. Similarly at stage II each client determines whether any of its input control setting values have changed within the last network clock period and, if so, control messages indicative of those changes are lo assembled in an input client update packet (I/P CUP) at the client. The I/P CUP is stored, awaiting transmission, in a client output buffer. If no changes to output controls have occurred in the last network clock period then a "null" client update packet will be sent by the host indicative of "no change". The null client update packet may alternatively comprise the current value of a randomly selected output device.

15 Similarly if there have been no changes to the input controls of a client in the last network clock period then a null client update packet will still be sent to the host. Again, the null client update packet may comprise the current value of a randomly selected user control. At stage III the variable n ( 1 < n < Nclients) is initialised to 1. This variable n is 20 an index for a current client device in a transmission sequence. The total number of client devices connected to the network is Nclients. At stage IV the host determines if n is less than (Nclients +1). The condition n = Nclients +1 occurs once all of the clients in the transmission sequence have made transmissions to the host in the period of time elapsed since the last network clock message was received at stage I. If n = (Nclients +1) at stage 25 IV the next network clock message is awaited by network devices, whereupon the process starts again from stage I. However, if n < (Nclients +1) at stage IV the process proceeds to stage V where the host transmits an output client update packet O/P CUP(n) to a client Sn. {Sn} (1 < n < Nclients) corresponds to a sequence in which each client is 30 represented, for example, S1 = client!, S2 = client 2, S3 = client 3 and so on. As explained below the ordering of the clients in this sequence may be changed following a transmission error. At stage VI the client receives the output client update packet OF CUP(n) and on receipt of this, proceeds to stage VII where an input client update packet

I/P CUP(n) is transmitted from client to host. At stage VIII, the host establishes whether it has received I/P CUP(n).

If the input client update packet has been received by the host then the process proceeds to stage IX where n is incremented and the transmission phase begins again 5 from stage IV for the next client in the transmission sequence {Sn}. If however I/P CUP(n) was not received at stage VIII the host awaits its receipt at stage X. Provided that I/P CUP(n2 arrives within the network clock period then as soon as the client update packet is received the process proceeds to stage IX. It is, in due course, determined by the host at stage XI whether I/P CUP(n) has been received within the current network lo clock period i.e. before receipt ofthe next network clock message.

If I/P CUP(n) is not received within the network clock period then an error is logged against the client at stage XII and an indication of occurrence of the error is given to the user. Such an error is a indication of possible failure of the client device in question. 5 The host proceeds from stage XII where the client error is logged, to reorder the client sequence {Sn} at stage XIII so that the client from which an input client update packet was not received is shunted to the end of the transmission sequence so that the failed client becomes the last to receive a client update packet in the next network clock period. In this way data transactions with clients that seem to be functioning are 20 completed before attempting to elicit a response from the client which failed to respond in the previous network clock period. Following sequence reordering at stage XIII, the process returns to stage II (the next network clock message having already been received at stage XI).

In each network clock period (provided no errors occur) the host transmits an O/P 25 CUP to each client and each client responds to this transmission by a client to host I/P CUP transmission. The iterated sequence of alternate host-to-client and client-to-host transmissions incorporates every client of the network. The first host-to-client transmission is initiated by receipt of a network clock message whereas subsequent host to-client transmissions are initiated by the host's receipt of an input client update packet 30 from a previous client in the sequence. Each client-to-host transmission is initiated by the given client's receipt of a host-to-client output client update packet.

:; 19 Figure 9 is a schematic block diagram illustrating a distributed audio control network comprising three fader control panels. The apparatus comprises a host 810 for controlling data processing operations, an Ethernet hub 820, a first client 830 known to the host as panel 2, a second client 840 known to the host as panel 3 and a third s client 850 known to the host as panel 5. Panel 1, Panel 3 and Panel 5 are audio mixing panels, each of which has a plurality of sliding fader control knobs. The position of each fader control knob on a sliding scale ultimately determines a gain (volume) setting of an audio channel, the audio data being processed under control of the host 810. The faders are motorised and the control knobs can thus be automatically set to predetermined levels lo under the control of the host 810. To effect an automated change to a position of a fader control knob, the host sends a control message to the client panel with an updated output control value for that fader. The position of the fader on the sliding scale gives the operator a visual indication of the setting of that control.

The format of a control data value indicating the position of a motorised fader knob on a sliding scale is given in Table 3 below. The data length is 2-bytes. The control message will be sent from client to host following manual adjustment of the fader control knob by the user or from host to client in the case of an automated adjustment of the fader knob setting.

Table 3

Data (hexadecimal) State Xaash Aaa | 12-bit linear position value: OxOOO is minimum/bottom | of fader knob travel, OxFFF is maximum/top of travel To enable the user to adjust a fader control knob manually, each fader is provided with a touch sensor that allows the apparatus to detect when a manual adjustment is being performed. When the touch sensor is detects an operator's finger(s) in contact with it 25 then a servo motor used for automated adjustment of the fader knob is inhibited. This prevents the servo from fighting against the operator as the fader is manually adjusted.

The fader control knobs are electrically conducting and are electrically charged by a touch detection circuit. When the operator touches the control knob a change in capacitance is effected and the servo is inhibited in response to this change in 30 capacitance. If more than one control knob is touched simultaneously then the operator's body capacitance will be spread across all of the control knobs being simultaneously touched. This can result in the body capacitance per fader being insufficient to trigger the

touch sensors that inhibit the servo motors. To overcome this problem, it is known to perform a "local scan" whereby fader controls on a given client fader panel are sequentially enabled to detect the touch of an operator. The known system according to which the local scan is performed is described in detail in the UK patent application GB 5 A-2 293 242. In brief, the local scan involves scanning the fader knobs in a chain of latches, clocked like a shift register at lOkHz. Accordingly each fader control knob is arranged to detect a change in capacitance on its conductive surface for only a limited "enabled" period of 10 seconds, generally arranged not to overlap or coincide with other "enabled" periods.

I o The fader panel will locally inhibit the servo when the corresponding control knob is touched (without the need for a control signal from the host to the fader panel). To prevent servo jitter, the fader panel locally inhibits the servo when the error in the absolute value of a difference between the required fader control knob position and the actual control knob position falls below a predetermined threshold. Furthermore, to 5 prevent servo burnout in the event that the fader becomes jammed, the fader panel locally inhibits the servo when the required position tolerance is not reached within a timeout period. Conko1 messages are transmitted from the client fader panel to the host for the purpose of informing the host of whether the fader control knob is being touched or no not. The control message is 1-byte long and has the format defined in Table 4 below (note that in the Table an x indicates a "don't care" logic value). Although there is a local connection within the client fader panel that serves to inhibit the servo associated with a fader, the conko1 message from client to host is still used. The client to host message is required for touch sensitive user interface devices used to control audio 25 processing functions such as a channel selection or a solo function or to control automation features such as read/write or mode select Table 4

Data (binary) State OxxxxxxO Switch is not touched Oxxxxxxl Switch is touched To initiate the local scan of a given client's fader panel the client device 30 processor places an enable pulse on the first of the touch detectors in the scan sequence of

the fader panel and clocks the pulse. Thus if there are eight faders on the panel, the enable pulse will emerge from the eighth fader in the sequence after axle seconds Although is known how to address the problem of shared body-capacitance on a given control panel by implementing a local scan, a further related problem arises in a 5 distributed audio control network comprising two or more different fader control panels situated at different network nodes. In this case the touch sensors of fader control knobs on different fader panels belong to different touch detection circuits so they cannot simply be scanned in a continuous sequence by scanning the touch detectors in a chain of latches.

The adverse effects of shared body-capacitance could arise when the operator lo simultaneously touches fader control knobs on two different fader panels (assuming that those control knobs happen to be simultaneously touch enabled). However, if the local scans were autonomous there would be no guarantee that two fader control knobs on different client panels will not be simultaneously touch enabled. For example, the operator could simultaneously touch a fader control knob on the second panel 830 and a 5 fader control knob on the fifth panel 850, which happens to have a coincident or partially overlapping responsive period. To avoid the problem of two faders on different panels being enabled simultaneously, the local scan initiation signal to each fader panel is temporally co-ordinated via the network so that they are no longer autonomous. This is achieved by triggering the local scans in a virtual ring or loop around the client fader 20 panels on the network according to a predetermined sequence that defines a "global scan". The host configures the global scan sequence by defining a "starter panel" and a subsequent ordered sequence of fader panels. The local scan on the starter panel is initiated by a network broadcast and subsequent scans in the sequence are initiated by client-to-client packet data communications between fader panels in the sequence. The 2s client-to-client communications in this particular embodiment use the UDP protocol.

However in alternative embodiments Fast IP is used instead of UDP. As described above, Fast IP is a proprietary NetSilicon protocol designed for real-time applications and it provides low-latency cornnunications across IP networks.

As shown in Figure 9, each panel in the global scan loop stores a flag 30 indicating whether or not it is the starter panel and also stores the IP address of the next panel in the loop. An illustrative example of a global scan process is illustrated in the flow chart of Figure 10.

In Figure 10, at stage 910 the host 810 determines that three fader panels are available in the audio network: panel 2, panel 3 and panel 5. The host defines the predetermined global scan sequence to be panel 2 which is designated the starter panel, followed by panel 3, followed by panel 5. The host sends control messages across the s network to inform panel 2 that it is the starter panel so the starter panel flag of panel 2 is set equal to 1. The host sends a message to panel 2 indicating the IP address of panel 3 which panel 2 stores in memory. Panel 3 is sent a message indicating the IP address of panel 5 which panel 3 stores in memory. Finally the host sends panel 5 the IP address of panel 2 which panel 5 stores in memory thus completing the circuit of the global scan lo configuration. At stage 920 of the flow chart, panel 2, which knows that it is the starter panel, receives a fader sample broadcast message that was transmitted by the host and initiates a local scan in response to that message by sending a scan enable pulse to the first fader control knob in its local scan sequence. Each fader touch sensor is then enabled for a non-overlapping period (although some overlap could be tolerated). When the scan 5 enable pulse emerges from the last fader in the local scan sequence of panel 2, panel 2 sends a scan synchronisation message via UDP addressed to the next panel in the sequence which is panel 3.

At stage 930 panel 3 receives the UDP synchronisation message that was sent by panel 2 and initiates its own local scan in response to receipt of this 20 synchronisation message. When the scan enable pulse emerges from the last fader of panel 3, panel 3 sends a scan synchronisation message via UDP addressed to the next panel in the sequence which is panel 5.

At stage 940 panel 5 receives the synchronisation message from panel 3 and this initiates its own local scan. When the scan enable pulse emerges from the last :5 fader of the local scan sequence of panel 5, panel 5 in turn sends a scan synchronisation message via UDP addressed to the starter panel, panel 2. At stage 950 panel 2 receives the scan synchronisation message from panel 5. At this stage Panel 2 does not initiate the next local scan immediately but effectively returns to stage 920 of the flow chart and waits until the next fader sample broadcast message is received before initiating the panel 30 2 local scan and thus starting the next cycle of the global scan sequence.

In this embodiment the local scan of the starter panel on each cycle of the global scan is initiated via a network clock message. However thelocal scans of client panels other than the starter panel are initiated without host intervention and are mediated

by client-to-client communications. In alternative embodiments the starter panel itself or another client device or indeed the host could be used to initiate the first local scan.

If a scan synchronization message is not received by a client panel that is part of the configured global scan sequence in any given network clock period then a scan 5 loop error message is sent to the host. In response to this error message the host suspends the current scan cycle, resets the global scan and issues a warning to the operator. The scan loop error message also serves to facilitate logging of touch switch scanning errors.

In alternative embodiments an acknowledgement is sent to the sending panel and/or to the host on receipt of the panel-to-panel synchronization signal.

lo The synchronization of devices of the audio control network has been explained above with reference to Figure 1. The fact that the audio control network is synchronized to within a predetermined tolerance allows for a system whereby timestamping of control messages via local real-time clocks of network devices is used to; provide consistent response latencies for audio control processes. The use of 15 timestamping will now be explained using several examples.

Figure 11 is a flow chart illustrating how "adjustment timestamps" are used to provide a substantially consistent response latency in a case where adjustment of a user-control at the client results in performance of an audio data processing task by the host. The example in the flow chart relates to gain (volume) adjustment on an audio 20 channel following adjustment of a fader knob. Further alternative examples of an audio processing task being triggered by a client-side operation include performance of a "mute" operation or a "cut" operation on an audio channel. In these cases the response latency relates to the delay between adjustment of the user control on the client side and the data processing operation being carried out at the host side.

2s At stage 1100 of Figure 11 the operator adjusts a fader knob setting which results in a control message indicative of the new setting and containing an adjustment timestamp being assembled and appended to an input client update packet at stage 1200.

Stage 1300 shows that the client update packet is stored in the client output buffer until a client update packet from the host indicating changes to output device settings (O/P CUP) 30 is received by the client at stage 1400, whereupon the input client update packet (I/P CUP) is transmitted from client to host. At stage 1500 the host receives the client update packet and extracts the control message indicative of the change to the fader knob setting.

The host stores this control message in the host input buffer until the local real-time clock reading coincides with a time corresponding to the adjustment tiestamp plus a

predetermined latency period. Once the control message is retrieved from the buffer at stage 160O, the host controls execution of the audio data processing task of gain adjustment on the appropriate audio channel.

Figurel2A is a schematic block diagram illustrating a client-side s perspective of the chain of events corresponding to the flow chart of Figure 11. In Figure 12A a touch detector 1110 detects an operator's fmger making contact with the fader knob. The detection can take place only at a time interval when the fader control is touch-detect enabled by a pulsed enable signal 1115. In response to the positive detection of a user's finger(s) on the fader knob, the fader panel controls the servo inhibitor 1120 to 0 effect inhibition of the servo motor associated with the fader knob being touched. The servo motor is used for automated adjustment of the fader knob but is inhibited to prevent it from resisting manual adjustment of the fader knob by the user. A change detector 1130 in the fader panel detects that the fader knob has been manually adjusted. The time, according to a local real-time clock 1140 at the fader panel, at which the change detector 5 1130 detected the knob adjustment is supplied to a message assembler 1210. The message assembler 1210 assembles a control message (using an appropriate data format) indicative of the new setting of the fader knob and includes a timestamp in the control message corresponding to the sum of the time at which the fader adjustment was detected plus a predetermined latency period. This control message is appended to a client update 20 packet. The client update packet containing the control message is transmitted across the network to the host following receipt of the next O/P CUP from the host. Figure 1 2B shows the corresponding sequence of events at the host. The client update packet is received by the host and the control message is stored in an input buffer (not shown) until the host real-time local clock reading coincides with the control message timestamp.

2s Once the control message is released from the input buffer the host uses the channel selector 1410 to determine to which audio channel data the control message corresponds.

The host then proceeds to perform gain adjustment 1620 on the appropriate audio data.

The predetermined latency period will determine the time lapse between adjustment of the fader knob and the audio data processing gain adjustment operation being performed.

30 Thus the operator should perceive a substantially constant response latency between the adjustment of a fader knob and a change in volume (gain) of the corresponding audio channel. Figure 13 schematically illustrates how control message time-stamping is used to achieve a substantially consistent response-latency in the case of a client-side user

I, -- 2s interface adjustment following from a client-side button press event. The Figure shows a time-line for the host alongside a corresponding time-line for a client. It is assumed for this example that we have zero drift so that the local clocks of the client and the host are in exact agreement from time t=0 to time P70.

5 At time t=O, the local real-time clocks of all the network device local processors are synchronized via a network broadcast synchronization (sync) message. Between network synchronization messages the local clocks at the clients run independently. The local clocks clock will typically be subject to clock drift due between synchronization messages, for example, due to small differences in frequencies of oscillation arising from lo physical variations in the underlying oscillators. However the clocks are synchronized to within a predetermined maximum tolerance.

At time t = 46, 0.046 seconds after the network synchronization broadcast, an operator presses a button (on the client device) associated with audio channel two. A Or control message indicative of the change in status of the button is consequently assembled 5 by the client and appended to an input client update packet I/P CUP( 1). The timestamp of the control message is t = 46 and is indicative of the client real-time clock reading at the time the user adjustment was detected. The packet I/P CUP(1) is queued, awaiting transmission, in an output buffer of the client device.

At time t = SO, 0.004 seconds after the operator pressed the button at the client, the 20 host receives a network clock message. Receipt of the network clock message initiates transmission of an output control message O/P CUP(1) from host to client. In this example, the client with which the pressed button is associated is in fact the first client in the predetermined transmission sequence {Sn} described above with reference to Figure 8. The packet O/P CUP(1) comprises control messages indicating output device status 25 changes that occurred in the previous network clock period.

At time t = 52, 0.002 seconds after receipt of the network clock message, the client receives O/P CUP(I) and consequently initiates retrieval of the packet I/P CUP(1) from the client output buffer and transmission of this packet occurs shortly after t=52.

At t = 56, 0.056 seconds after the network sync broadcast, I/P CUP(1) is received 30 by the host. The packet I/P CUP1 is disassembled and its constituent control messages are stored in the host input buffer. The control message indicative of the button-press event is timestamped with a value t = 46 + 12 =58, corresponding to the sum of the time at which the button-press event was detected by the client and a first predetermined latency period of 0.012s. This control message is retrieved from the input buffer at P58

whereupon the host performs the audio processing function associated with the button press. In executing the control message the host also determines that a corresponding change to an output device is required. In particular, a light emitting diode (LED) located 5 beneath the button on the client panel must be illuminated to indicate the current button status. The host assembles an output control message indicating that the LED should be illuminated and appends this control message to the output client update packet O/P CUP2. The control message instructing LED illumination is timestamped with a value corresponding to the sum of the detection of the button-press at the client (as indicated by 0 the control message on I/P CUM1) plus a second predetermined latency period of 0.026 seconds i.e. t = 46 + 26 = 72. This timestamp is defined in dependence upon the time at which the button was pressed by the operator in order to ensure a substantially consistent response latency between the button-press at the client and LED illumination at the client.

It is apparent that, in this example, the second predetermined latency period which IS defines the time at which the output device status changes, is necessarily greater than the first predetermined latency period which defines the time at which the audio processing is executed. At t = 60, 0.01 seconds after the previous network clock message, the next network clock message is received. Receipt of the network clock message at t = 60 20 initiates transmission of O/P CUP(2) from the host to the client. The message O/P CUP(2) is received by the client at t=64 whereupon it is disassembled into control messages. The control message instructing illumination of the LED is stored in the client input buffer until the client's local real-time clock coincides with the control message timestamp t=72. At t=72 the control message is executed. Accordingly the LED lights 25 up at or very close to the desired 0.026 seconds after the button-press event.

Figure 14A is a schematic block diagram illustrating the sequence of events arising from an operator adjusting a user control setting on a client panel. Figures 14A and 14B correspond to events on the timeline of Figure 13.

In Figure 14A the operator presses the button 1710 on the panel of the 30 client device and a change detection module 1720 in the client registers the status change and associates it with a local control ID corresponding to the particular button. The data from the change detector 1720 is then passed to a message assembler module 1740 at the client which assembles a client update packet including a control message indicative of the button press operation. A local real-time clock 1730 provides a timestarnp for the

I 27 control message corresponding to a time when the status change of the button was detected by the client (tag) plus the first predetermined latency period (LPI) of 0.012s.

The client update packet is stored at the client side in an output buffer 1750 until transmission to the host is initiated by receipt of an O/P CUP from the host. The client s update packet indicative of the button-press corresponds to message I/P CUP(1) in the flow chart of Figure 13. The host performs the audio processing function at t = tag +LP1 and subsequently assembles the output client update packet O/P CUP(2) comprising the control message giving instructions to illuminate the LED associated with the pressed button. This output control message is timestamped with the time t = tag +LP2, where lo LP2 is the second predetermined latency period of 0.026s.

Figure 14B shows a return control message arriving at the client. This return control message corresponds to O/P CUM2 in the flow chart of Figure 13. The return control message containing instructions to illuminate an LED corresponding to the pressed button is stored in a client input buffer 1760 until the time according to the local 15 real- time clock 1770 coincides with the timestarnp on the return control message, whereupon the control message is retrieved from the buffer and executed and the LED is illuminated. The timestamp on the return control message corresponds to the time when the button was pressed at the client plus a predetermined latency period. Thus the LED is illuminated after a suitable delay of around 0.026s, measured from the button-press 20 event. The delay in LED illuminations should be consistent with the predetermined latency period to within the maximum allowable clock drift tolerance for each button press.

Claims (20)

1. Data processing apparatus comprising: two or more client devices, each client device having one or more user controls, s each user control having an associated touch sensor having an enabled state in which it is arranged to detect a touch by a user and a quiescent state in which it is arranged not to detect such a touch; a host device operable to control data processing operations in dependence upon a status of the one or more user controls; lo a network for providing a data communications path connecting the host device and the two or more client devices; in which each client device is operable to perform a local scan in which one or more touch sensors at that client device are changed from the quiescent state to the enabled state for a respective enabled period; and 5 in which the host is operable to configure a global scan comprising a predetermined sequence of local scans, consecutive local scans in the predetermined sequence being initiated by client-to-client data communications.

2. Apparatus according to claim 1, in which the enabled period corresponding to JO each touch sensor in a local scan is at least partially non-coincident with the enabled periods of other touch sensors at that client.

3. Apparatus according to claim 1 or claim 2, in which the host is operable to configure the global scan such that local scans in the predetermined sequence are non 2s overlapping in time.

4. Apparatus according to any one of the preceding claims, in which each client device in the predetermined sequence of local scans is operable to store a network address for a next client in the predetermined sequence and an indication of whether or not the 30 client device is a first client in the predetermined sequence.

5. Apparatus according to claim 4, in which a first local scan corresponding to a first client in the predetermined sequence is initiated by the host.

P/ 29

6. Apparatus according to claim 4, in which a first local scan corresponding to a first client device in the predetermined sequence is initiated by the first client device in response to a network broadcast message.

s

7. Apparatus according to claim 6, in which a last client corresponding to a last local scan in the predetermined sequence is operable to send a client-to-client communication to the client device corresponding to a first local scan in the predetermined sequence.

8. Apparatus according to any one of the preceding claims, in which each local scan lo is arranged to enable each touch sensor at that client device for a respective enabled period.

9. Apparatus according to any one of the preceding claims, in which: the apparatus provides the functionality of an audio workstation, and at least some of the user controls are fader knobs having an associated motorising -a arrangement which, when the associated touch sensor detects a touch by the user, are arranged to inhibit operation of the motorising arrangement. -it

10. Apparatus according to any one of the preceding claims, in which the client-to-client so communications are packet data transmissions.

11. Apparatus according to claim 10, in which the packet data transmissions are user datagram protocol (UDP) messages.

25

12. Apparatus according to claim 10, in which the packet data transmissions are internet protocol messages.

13. Apparatus according to any one of the preceding claims, in which each client device corresponding to a local scan in the predetermined sequence is operable to send an 30 acknowledgement to the host or to another of the client devices on receipt of the client-to-

client message.

14. Data processing apparatus substantially as hereinbefore described with reference to the accompanying drawings.

r 30

15. A method of operation of a data processing apparatus comprising two or more client devices, each client device having one or more user controls, each user control having an associated touch sensor having an enabled state in which it is arranged to detect 5 a touch by a user and a quiescent state in which it is arranged not to detect such a touch; a host device operable to control data processing operations in dependence upon a status of the one or more user controls; and a network for providing a data communications path connecting the host device and the two or more client devices; the method comprising the steps of: lo each client device performing a local scan in which one or more touch sensors at that client device are changed from the quiescent state to the enabled state for a respective enabled period; the host configuring a global scan comprising a predetermined sequence of local scans; is client devices initiating consecutive local scans in the predetermined sequence being by client-to-client data communications.

16. A data processing method substantially as hereinbefore described with reference to the accompanying drawings.

17. Computer software having program code for carrying out a method according to claim 15 or claim 16.

18. A providing medium for providing software according to claim 17.

19. A medium according to claim 18, the medium being a storage medium.

20. A medium according to claim 18, the medium being a transmission medium.