오픈 사운드 컨트롤(영어: Open Sound Control, OSC)은 음악 공연이나 쇼 컨트롤과 같은 목적을 위해 신시사이저, 컴퓨터, 기타 멀티미디어 장치를 연결하는 프로토콜이다. OSC의 장점으로는 상호운용성, 정확성, 유연성, 상세한 문서화 등이 있다. 반면 MIDI와 같은 대안에 비해 대역폭 요구량이 높고 임베디드 시스템 프로세서에 가해지는 부하가 크다는 점, 그리고 장치 간 메시지 표준화가 부족하다는 점이 단점으로 꼽힌다. 최초의 사양은 2002년 3월에 발표되었다.
OSC는 에이드리언 프리드(Adrian Freed)와 맷 라이트(Matt Wright)가 CNMAT에서 개발한 콘텐트 포맷으로, XML, WDDX, JSON에 비견된다. 본래 음악 악기(특히 신시사이저와 같은 전자 악기), 컴퓨터, 기타 멀티미디어 장치 간에 음악 공연 데이터(제스처, 매개변수, 음표 시퀀스)를 공유하기 위해 고안되었다. OSC는 높은 해상도와 더 넓은 매개변수 공간이 필요할 때 1983년에 제정된 MIDI 표준의 대안으로 사용되기도 한다. OSC 메시지는 UDP/IP와 이더넷을 사용하여 인터넷과 로컬 서브넷 내에서 전송된다. 제스처 컨트롤러 간의 OSC 메시지는 보통 SLIP 프로토콜로 래핑되어 USB의 시리얼 엔드포인트를 통해 전송된다.
MIDI와 비교한 OSC의 주요 기능은 다음과 같다.
OSC는 실시간 사운드 및 미디어 처리 환경, 웹 상호작용 도구, 소프트웨어 신시사이저, 프로그래밍 언어, 하드웨어 장치 등 수십 가지 응용 분야에서 사용된다. OSC는 음악적 표현, 로봇 공학, 비디오 공연 인터페이스, 분산 음악 시스템, 프로세스 간 통신 등 다양한 분야에서 널리 사용되고 있다.
멀티터치와 같은 접촉식 인터페이스를 위한 TUIO 커뮤니티 표준이 OSC를 기반으로 구축되었으며, 제스처를 표현하기 위한 GDIF 시스템 역시 OSC를 통합하고 있다.
OSC는 실험적인 음악 컨트롤러에 광범위하게 사용되며, 여러 오픈 소스 및 상용 제품에 내장되어 있다.
Open Sound World(OSW) 음악 프로그래밍 언어는 OSC 메시징을 중심으로 설계되었다.
OSC는 DSSI(Disposable Soft Synth Interface) 플러그인 API의 핵심으로, LADSPA API의 진화된 형태이며, GUI가 플러그인 호스트와 메시지를 주고받으며 플러그인 코어와 상호작용하도록 한다. LADSPA와 DSSI는 오디오 효과와 신시사이저를 위한 전용 API이다.
2007년에는 컨트롤러, 신시사이저, 호스트 간 통신을 위해 OSC 내에 표준화된 이름공간인 SYN이 제안되었다.
OSC 메시지는 주소 패턴(예: /oscillator/4/frequency), 유형 태그 문자열(예: float32 인자 뒤에 int32 인자가 오는 경우 ,fi), 그리고 인자 자체(타임스탬프 포함 가능)로 구성된다. 주소 패턴은 유닉스 파일 시스템 경로 또는 URL을 연상시키는 계층적 이름공간을 형성하며, 서버 내부의 메서드를 참조하여 첨부된 인자와 함께 호출된다. 유형 태그 문자열은 인자 유형을 압축하여 표현한 것이다. 인자는 4바이트 정렬을 사용하여 이진 형식으로 표현된다. 지원되는 핵심 유형은 다음과 같다.
사양에 포함된 메시지 예시(널 패딩 바이트는 ␀로 표시): /oscillator/4/frequency␀,f␀␀, 그 뒤에 440.0의 4바이트 float32 표현인 0x43dc0000이 이어진다.
메시지는 번들로 결합될 수 있으며, 이 번들이 다시 다른 번들과 결합될 수도 있다. 각 번들에는 타임스탬프가 포함되어 있어 서버가 즉시 응답할지 혹은 미래의 특정 시점에 응답할지를 결정한다.
응용 프로그램은 일반적으로 이러한 핵심 세트에 대한 확장을 사용한다. 최근에는 불리언(Boolean) 유형과 같은 일부 확장이 OSC 1.1의 필수 핵심 유형에 통합되었다.
MIDI에 비해 OSC가 갖는 장점은 주로 인터넷 연결성, 자료형 해상도, 그리고 모든 연결을 7비트 숫자나 7/14비트 자료형으로 지정하는 대신 기호 경로를 쉽게 지정할 수 있다는 점이다. 그러나 이러한 인간 가독성은 전송 효율이 떨어지고 임베디드 펌웨어에서 파싱하기가 더 어렵다는 단점이 있다.
사양은 특정 OSC 메서드나 OSC 컨테이너를 정의하지 않는다. 모든 메시지는 구현에 따라 정의되며 서버마다 다르다.
one of the reasons OSC has not replaced MIDI yet is that there is no connect-and-play … There is no standard namespace in OSC for interfacing e.g. a synth
OSC suffers from a superset of this problem: it’s anarchy, and deliberately so. The owners of the specification have been so eager to avoid imposing constraints upon it that it has become increasingly difficult for hardware to cope with it. … More severely, there is an interoperability problem. OSC lacks a defined namespace for even the most common musical exchanges, to the extent that one cannot use it to send Middle C from a sequencer to a synthesiser in a standardised manner
OSC also introduces new obstacles. First, since there is no fixed set of messages, each participating server needs to know what messages it can send to the servers it intends to communicate with. Currently the OSC standard does not provide for a means of programmatically discovering all messages a server responds to