Proposal for OpenSound Control Specification Amendment

Second Draft, May 1 2005, Richard Healy

0.0 Introduction

This is a proposal for amendment to the OSC specification. The proposed amendment provides a mechanism to uniquely identify OSC Message(s) using a new OSC data type OSC ID. This revision simplifies the OSC ID and makes no assumptions about the transport, the implementation or the communication model used.

1.0 The OSC ID

It is proposed that a new definition "OSC ID" be added to the OSC specification. Its purpose is to uniquely identify any OSC Message.

OSC ID {
    OSC String OSCIDTag
    OSC Blob   OSCIDData
}

The OSC ID consists of two fields "OSCIDTag" and "OSCIDData".

OSCIDTag Field
The OSCIDTag field consists of an eight byte OSC String with the value "#osc_id"

OSCIDData Field
The OSCIDData field consists of an OSC Blob which contains the ID data.

Example of a proposed OSC ID containing four bytes of ID data:

#osc_id[0x00][0x00000004][0x12345678]

1.1 Insuring OSC ID Uniqueness

The proposed OSC ID must be unique enough to insure that there are no collisions between two OSC Message ID's in a given context. The context is implementation specific. A collision is defined as an exact byte by byte match of the OSCIDData field of the OSC ID's being compared.

2.0 References

Wright, M. (2002). OpenSound Control Specification Version 1.0.