Sound Control Protocol Digital 6000 (EM 6000 | L 6000)

SSC Developer‘s guide for Digital 6000 | 13/57
SSC subscriptions - /osc/state/subscribe
5. SSC subscriptions - /osc/state/subscribe
A subscription request is sent by a client to a server for an address pattern to subscribe to. The SSC
Server normally accepts the subscription request, and remembers that the requesting client wishes
to be notified about value changes of the subscribed addresses.
The SSC Server MAY refuse subscription requests, subject to device-specific policy or implementa-
tion specific limitations. The SSC Server MUST reply on the subscription request immediately either
by acknowledging the request, or by sending an error reply.
The SSC Server MUST send an initial subscription notification to the client, which contains the re-
sult of calling the subscribed SSC Methods immediately with null-argument when the subscription
request is handled. This initial notification MAY be bundled with the reply to the subscription request
itself.
Each subscription notification MUST have identical contents to the reply to an imagined SSC Method
invocation with null-argument to the subscribed SSC Method Address at the time that the notifica-
tion is sent.
The SSC Client MAY bundle a call to /osc/xid with the subscription request. If a xid is supplied,
a reply to /osc/xid MAY be bundled with each subscription notification, with the xid of the reply
identical to that supplied by the client.
The SSC Server MUST send value changes of the subscribed addresses to the SSC Client. By default,
the SSC Server will send subscription notifications if and only if the subscribed addresses change
in value. The SSC Client can modify this behaviour by supplying optional parameters with the sub-
scription request, allowing to either throttle the rate of notifications, or stimulate additional periodic
notifications even if the subscribed addresses do not change in value.
Every subscription is specific to the connection between SSC Client and SSC Server. Also each SSC
Method can only be subscribed once per connection. This means, that if a SSC Client requests a sub-
scription which is already subscribed by that client on that connection, then the SSC Server MUST
treat this as if the existing subscription was silently terminated and immediately requested anew.
5.1 Subscription notification rate parameters
Optional subscription request parameters related to notification rate:
• "min" minimum notification period (ms), 0=none, default 0
• "max" maximum notification period (ms), 0=none, default 0
If "min" is 0, then notifications are not sent when a subscribed address changes in value, they are
only sent based on the "max" period. If "min" is greater than 0, notifications are sent after the spec-
ified time duration has elapsed, even if the value of the subscribed address is unchanged. If "max"
is 0, then notifications are only sent when a value changes, or based on the "min" period. If "max" is
greater than 0, then notifications are sent not earlier before the specified time duration has elapsed,
even if the subscribed address changes value in the meantime.
5.2 Subscription cancelling and expiration
The SSC Server MUST terminate a subscription in these cases:
• the subscribed client cancels the subscription explicitly
• a maximum number of notifications has been sent
• a maximum lifetime relating to the begin of the subscription expires
• the SSC Client closes the connection
• the transport layer of the SSC connection signals a communication error
If the SSC Server decides to terminate the connection because the lifetime or notification count ex-
pires, then it MUST inform the SSC Client by sending an error reply "310 – subscription terminated"
to the SSC address that terminates subscription together with or immediately after the last subscrip-
tion notification.