Proposal for OpenSound Control Specification Amendment

Third Draft, May 6 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 fixes the accidental omission of section 1.2.

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.

1.2 OSC ID In The OSC Message

The OSC ID is put before the OSC Address Pattern in an OSC Message. The OSC ID is optional and only necessary if the client wishes to uniquely identify the OSC Message.

2.0 References

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