RTP-MIDI

이 글은 인용 문체가 불분명하다 사용된 참조는 인용 및 각주를 달리하거나 일관된 스타일로 명확하게 할 수 있습니다.(2022년 5월) (이 템플릿메시지를 삭제하는 방법과 타이밍을 학습합니다)

RTP-MIDI

국제 표준	IETF RFC 4696
개발자	UC 버클리
웹 사이트	www.midi.org/midi-articles/rtp-midi-or-midi-over-networks

RTP-MIDI(AppleMIDI라고도 함)는 이더넷 및 WiFi 네트워크를 통해 RTP(Real-Time Protocol) 패킷 내의 MIDI 메시지를 전송하는 프로토콜입니다.완전히 오픈되어 무료(라이선스가 필요 없음)이며 LAN 및 WAN 응용 프로그램필드 모두와 호환됩니다.MIDI 1.0과 비교하여 RTP-MIDI에는 세션 관리, 디바이스 동기화 및 손실된 패킷 검출 등의 새로운 기능과 손실된 데이터의 자동 재생성이 포함되어 있습니다.RTP-MIDI는 실시간애플리케이션과 호환성이 있어 각 MIDI 메시지에 대해 샘플 정밀도의 동기화를 지원합니다.

RTP-MIDI 이력

2004년 UC 버클리 출신의 John Lazzaro와 John Wawrzynek은 AES 앞에서 "MIDI를 위한 RTP 페이로드"^[1]라는 이름의 프레젠테이션을 했다.2006년에 이 문서는 IETF에 제출되어 RFC 4695라는 ^[2]번호를 받았습니다.이와 동시에, Lazzaro와 Wawrzynek는 RTP-MIDI 프로토콜, 특히 저널링 ^[3]메커니즘의 실질적인 구현에 대한 세부사항을 제공하는 또 다른 문서를 공개했다.

RFC 4695는 2011년에 RFC 6295에 의해 폐지되었습니다.이 프로토콜은 두 버전의 RFC 문서 간에 변경되지 않았습니다. 마지막 버전은 RFC 4695에서 ^[4]발견된 오류 수정을 포함합니다.)

MMA(MIDI Manufacturers Association)는 RTP-MIDI ^[5]프로토콜과 관련된 기본 정보를 제공하기 위해 홈페이지에 페이지를 만들었습니다.

Apple MIDI

Apple Computer는 2005년에 운영 체제인 Mac OS X v10.4의 일부로 RTP-MIDI를 도입했습니다.RTP-MIDI 드라이버에 액세스 하려면 , MIDI/Audio Configuration 툴의 Network(네트워크) 아이콘을 사용합니다.Apple의 실장은 RTP 페이로드 및 저널링 시스템에 대해서는 RFC 4695를 엄격하게 준수하지만 전용 세션 관리 프로토콜을 사용합니다.이러한 프로토콜은 RFC 4695 세션 관리 제안을 따르지 않습니다.이 프로토콜은 Wireshark에 "AppleMIDI"로 표시되며 나중에 Apple에 의해 문서화되었습니다.

또한 Apple은 mDNS/Bonjour 구현에서 전용 클래스를 만들었습니다.이 클래스에 준거한 디바이스는, Apple의 RTP-MIDI 설정 패널에 「Participants(참가자)」디렉토리로 자동적으로 표시되기 때문에, Apple MIDI 시스템은 완전하게 「플러그 앤 플레이」가 됩니다.다만, 이 디렉토리에 IP 주소와 포토를 수동으로 입력해, Bonjour 를 서포트하고 있지 않는 디바이스에 접속할 수 있습니다.

또한 Apple은 iOS4에서 RTP-MIDI 지원을 도입했지만 이러한 장치는 세션 이니시에이터가 될 수 없습니다.

Apple의 RTP-MIDI 드라이버는 "Sessions"라는 이름의 가상 MIDI 포트를 생성합니다.이 포트는 CoreMIDI를 사용하는 모든 소프트웨어(시퀀서나 소프트웨어 기기 등)에서 MIDI 포트로 사용할 수 있으며, 다른 MIDI 1.0 또는 USB 포트와 마찬가지로 MIDI IN/MIDI OUT 포트 쌍으로 나타납니다.

실장

임베디드 기기

2006년, 네덜란드의 Kiss-Box사는, MIDI 나 LTC ^[6]인터페이스등의 다양한 제품에 RTP-MIDI 를 최초로 실장했습니다.이러한 장치는 동일한 세션 관리 프로토콜을 사용하여 Apple MIDI 구현을 준수하며, 이 프로토콜을 사용하는 다른 장치 및 운영 체제와 호환됩니다.

Windows XP 용으로 동사가 독자 드라이버를 개발했지만, 디바이스와의 통신에 한정되어 있어, 이 드라이버를 사용해 PC와 Mac 컴퓨터를 접속할 수 없었습니다.이 드라이버의 지원은 2012년 Windows용 rtpMIDI 드라이버가 제공되기 시작하면서 중단되었습니다.

Kiss-Box는 2012년에 세션 이니시에이터 기능을 지원하는 "V3"라는 새로운 세대의 CPU 보드를 출시했다고 발표했습니다.이러한 모델에서는 컨트롤 포인트로 컴퓨터를 필요로 하지 않고 다른 RTP-MIDI 디바이스와의 세션을 확립할 수 있습니다.

NAMM 2013에서 캐나다 기업 iConnectivity는 iConnectivity라는 새로운 인터페이스를 발표했습니다.MIDI4+: RTP-MIDI를 지원하며 USB 디바이스와 RTP-MIDI 디바이스 간의 직접 브리징이 가능합니다.그 후 mio4 및 mio10, Play를 포함한 다른 RTP-MIDI 지원 인터페이스도 몇 가지 추가되고 있습니다.오디오 12

창문들

2010년, Tobias Erichsen은, Apple의 ^[7]RTP-MIDI 드라이버의 Windows 실장을 발표했습니다.이 드라이버는 XP,^[8] Vista, Windows 7, Windows 8 및 Windows 10, 32 및 64비트 버전에서 작동합니다.드라이버는 Apple과 매우 유사한 구성 패널을 사용하며 Apple의 구현과 완전히 호환됩니다.그런 다음 윈도우즈 시스템을 매킨토시 시스템뿐만 아니라 내장된 시스템과 연결하는 데 사용할 수 있습니다.Apple 드라이버와 마찬가지로 Windows 드라이버는 가상 MIDI 포트를 만듭니다.이 포트는 PC에서 실행되는 모든 MIDI 애플리케이션에서 볼 수 있습니다.액세스는 다른 모든 MIDI 포트와 마찬가지로 mmsystem 레이어를 통해 이루어집니다.

리눅스

Linux에 대한 RTP-MIDI 지원은 유휴 기간 후 2013년 2월에 다시 활성화되었습니다.일부 포럼에서는 니콜라스 팔케와 도미니크 포버의 ^[9][10]원작을 바탕으로 드라이버 이용 가능 여부가 발표되었습니다.

Rasberry PI 컴퓨터를 위한 특정 구현인 raveloxmidi도 ^[11]사용할 수 있습니다.

RTP-MIDI(저널링 시스템 포함)의 완전한 실장은 Ubuntu 배포, Science 소프트웨어 ^[12]패키지에서 사용할 수 있습니다.

새로운 실장 rtpmidid는 ^[13]ALSA 시퀀서와 심리스하게 통합되어 QjackCtl 등의 툴을 사용하여 접속을 제어할 수 있습니다.

iOS

애플은 2010년 iOS 기기에 CoreMIDI를 전면 지원함으로써 아이폰, 아이패드, 아이팟용 MIDI 애플리케이션을 개발할 수 있게 되었습니다.MIDI는 도킹 포트에서 USB 컨트롤러의 형태로 사용할 수 있게 되어 "Apple Camera Kit"를 사용하여 USB MIDI 장치를 연결할 수 있게 되었습니다.WiFi를 통한 RTP-MIDI 세션청취자의 형태로도 이용할 수 있었습니다.

iOS 장치는 세션 시작 기능을 지원하지 않습니다. iPad와의 RTP-MIDI 세션을 열려면 네트워크에서 외부 세션 이니시에이터를 사용해야 합니다.이 세션 이니시에이터는 Mac 컴퓨터 또는 RTP-MIDI 드라이버가 활성화된 Windows 컴퓨터 또는 내장된 RTP-MIDI 장치일 수 있습니다.RTP-MIDI 세션은 iOS 상의 모든 CoreMIDI 응용 프로그램에 "Network MIDI"라는 이름으로 표시되며 iOS 응용 프로그램에서 RTP-MIDI 지원을 추가하기 위해 특별한 개발이 필요하지 않습니다.MIDI 포트는 Core MIDI에 의해 가상화되므로 포트가 USB에 연결되어 있는지 RTP-MIDI에 연결되어 있는지에 관계없이 프로그래머는 MIDI 연결만 열면 됩니다.

iPad/iPhone은 외부 장치에 전원을 공급해야 하기 때문에 iOS ^[14]장치에서 MIDI over USB를 사용하는 것에 대한 불만이 제기되었습니다.일부 USB MIDI 어댑터는 iPad에 너무 많은 전류를 소비하므로 전류가 제한되고 장치의 시작이 차단되므로 응용 프로그램에서 사용할 수 없는 것으로 나타납니다.이 문제는 RTP-MIDI를 사용함으로써 회피됩니다.

자바스크립트

2013년 6월부터 J가 작성한 RTP-MIDI의 Javascript 구현.Dachtera는 오픈 소스 ^[15]프로젝트로 사용할 수 있습니다.소스 코드는 Apple의 세션 관리 프로토콜을 기반으로 하며 세션 이니시에이터 및 세션 청취자 역할을 할 수 있습니다.

자바

RTP-MIDI의 크로스 플랫폼 Java 구현, 특히 'nmj'^[16] 라이브러리가 가능합니다.

WinRT

WinRTP-MIDI 프로젝트는 Windows RT에서 RTP-MIDI 프로토콜 스택의 오픈 소스 구현입니다.이 코드는 처음에는 다양한 버전의 Windows 간에 이식 가능하도록 설계되었지만, 마지막 버전은 Windows Store용 애플리케이션 설계를 단순화하기 위해 WinRT용으로 최적화되었습니다.

아르두이노

RTP-MIDI는 2013년 11월 "AppleMIDI 라이브러리"^[18]라는 이름으로 Arduino 플랫폼에 제공되었습니다.소프트웨어 모듈은 인텔 Galileo와 같은 내장 이더넷 어댑터를 갖춘 Arduino 모듈 또는 "이더넷 실드"에서 실행할 수 있습니다.

KissBox는 SPI 버스 링크를 통해 연결되는 외부 통신 프로세서 보드인 RTP-MIDI OEM 모듈을 생산합니다.

MIDIbox

2013년 12월, MIDIbox DIY 그룹의 2명이 고속 SPI 링크를 통한 RTP-MIDI 지원을 포함한 MIOS(MIDIbox Operating System)의 초기 버전 작업을 시작했습니다.통합을 단순화하기 위해 전체 프로토콜 스택을 처리하는 외부 네트워크 프로세서 보드를 사용하기로 결정했습니다.첫 번째 베타 버전은 2014년 ^[19]1월 둘째 주에 출시되었습니다.첫 번째 공식 소프트웨어는 2014년 3월 첫째 주에 출시되었습니다.

MIOS 프로세서와 네트워크 프로세서 간의 SPI 링크에 사용되는 프로토콜은 USB와 동일한 형식을 기반으로 완전한 MIDI 메시지를 포함하는 32비트 단어를 사용하며 네트워크 프로세서 모듈과 MIDI 애플리케이션 보드 간의 통신을 위한 개방형 표준으로 제안되었습니다.

액솔로티

Axoloti는 STM32F427 ARM 프로세서를 기반으로 하는 오픈 소스 하드웨어 신시사이저입니다.이 신시사이저는 Max/MSP와 유사한 가상 패치 개념을 사용하여 완전히 프로그래밍 가능하며 MIDI를 완전히 지원합니다.node.js 확장은 임의의 RTP-MIDI ^[20]디바이스와의 Axoloti의 RTP-MIDI 접속을 가능하게 하기 위해 개발되었습니다.Axoloti 하드웨어에는 RTP-MIDI 외부 코프로세서를 장착할 수도 있습니다.이 코어는 Axoloti 코어의 확장 포트에 있는 SPI 버스를 통해 연결됩니다.이 방법은 Arduino 및 MIDIbox에서 설명한 것과 동일합니다.

MIDIKit 크로스 플랫폼 라이브러리

MIDIKit은 오픈 소스 크로스 플랫폼 라이브러리입니다.이 라이브러리는 시중에서 이용 가능한 다양한 MIDI API(코어 MIDI, Windows MME, Linux ALSA 등)를 위한 통합 MIDI API를 제공합니다.MIDIKit은 저널링 시스템을 포함한 RTP-MIDI 프로토콜을 지원합니다.RTP-MIDI 포트는 MIDIKit 내에서 원어민 시스템 MIDI 포트에^[21] 추가된 보완 포트(rtpMIDI 드라이버에 의존하지 않음)로 인식됩니다.

드라이버리스 사용

RTP-MIDI는 UDP/IP에 기반하기 때문에 어떤 애플리케이션도 드라이버 없이 프로토콜을 직접 구현할 수 있습니다.드라이버가 필요한 것은, 유저가 네트워크상의 MIDI 포토를 표준 MIDI 포토로서 표시하는 경우 뿐입니다.예를 들어 일부 Max/MSP 개체와 VST 플러그인은 이 방법을 따라 개발되었습니다.

RTP-MIDI over AVB

AVB는 이더넷네트워크상의 극히 낮은 레이텐시 스트리밍 서비스의 사양을 정의하는 일련의 기술 표준입니다.AVB 네트워크는, 네트워크 전체에 걸쳐, 1개의 음성 샘플까지 지연을 제공할 수 있습니다.
AVB 스위치("IEEE802.1 스위치"라고도 함)는 실시간 오디오/비디오 스트림과 IP 트래픽 사이의 우선순위를 자동으로 관리하므로 RTP-MIDI는 다른 IP 프로토콜과 마찬가지로 AVB 네트워크와 기본적으로 호환됩니다.RTP-MIDI 프로토콜은 디바이스가 IEEE-1733 ^[22]문서에서 설명된 RTCP payload를 구현하는 경우에도 AVB의 실시간 기능을 사용할 수 있습니다.그 후, RTP-MIDI 애플리케이션은, IEEE-802.1 마스터 클락에 의해서 제공되는 「프레젠테이션」타임 스탬프를 RTP 타임 스탬프와 관련지을 수 있기 때문에, MIDI 이벤트의 샘플의 정확한 시각 분포를 확인할 수 있습니다.

프로토콜

RFC 4695/RFC 6295 에서는, RTP-MIDI 의 실장이 다른 부분으로 분할되고 있습니다.RTP-MIDI 사양에 대한 준거를 정의하는 유일한 필수 사양은 페이로드 형식입니다.저널링 부분은 옵션입니다만, RTP-MIDI 패킷은 빈 저널이 있는 것을 나타내므로, 저널은 빈 경우에도 항상 RTP-MIDI 패킷에 존재합니다.세션 시작/관리 부분은 순전히 정보 제공입니다.자체 세션 관리 프로토콜을 만든 애플은 이 프로토콜을 사용하지 않았습니다.

헤더 형식

RTP-MIDI 헤더 형식

부분	조금	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
RTP	0	V		P	X	참조				M	페이로드 타입(PT)							시퀀스 번호
	32	타임스탬프
	64	Synchronization Source(SSRC; 동기화 소스) 식별자
	96	기여 소스(CSRC) 식별자(옵션)
	…	…
MIDI 명령어	…	B	J	Z	P	렌...				MIDI 메시지 목록...
저널(J 플래그에 따라 선택 사항)	…	S	Y	A	H	토찬				체크포인트 패킷 Seqnum																시스템 저널(옵션)...
		채널 저널...

세션

RTP-MIDI 세션은 2개의 RTP-MIDI 디바이스 간의 가상 경로 작성을 담당합니다.이러한 세션은 어플리케이션의 관점에서 MIDI IN/MIDI OUT 쌍으로 나타납니다.RFC 6295는 SIP(Session Initiation Protocol)와 SDP(Session Description Protocol) 사용을 제안하지만 애플은 자체 세션 관리 프로토콜을 만들기로 결정했습니다.애플의 프로토콜은 본쥬르에서 사용되는 이름과 세션을 연결하며 클럭 동기화 서비스도 제공한다.

1개의 세션은 항상 2개의 참가자 사이에 작성되며, 각 세션은 2개의 참가자 간의 메시지 손실을 검출하기 위해 사용됩니다.단, 특정 세션컨트롤러는 여러 세션을 병렬로 열 수 있으므로 분할, 병합 또는 분산 패치베이 등의 기능을 사용할 수 있습니다.여기서 나타내는 그림에서는 디바이스1은 디바이스2와 디바이스3의 2개의 세션이 동시에 열려 있는데 디바이스1의 2개의 세션은 최종 사용자에게 동일한 가상 MIDI 인터페이스로 나타납니다.

세션 대 엔드포인트

일반적인 실수는 RTP-MIDI 엔드포인트와 RTP-MIDI 세션이 모두 MIDI IN/MIDI OUT 포트의 쌍을 나타내기 때문에 불일치입니다.

엔드포인트는 RTP-MIDI 트랜스포트 프로토콜 복호화를 담당하는 요소(소프트웨어 및/또는 하드웨어)와 MIDI 메시지를 사용하여 요소 간에 MIDI 데이터를 교환하기 위해 사용된다.즉, MIDI 데이터만 엔드포인트 수준에서 볼 수 있습니다.MIDI 1.0 DIN 커넥터가 있는 디바이스의 경우 커넥터 쌍당 엔드포인트가 1개 있습니다.예를 들어 KissBox MIDI2TR의 경우 엔드포인트 2개, iConnectivity의 경우 엔드포인트 4개 등입니다.MIDI4+ 등SPI 또는 USB 등의 다른 통신 링크를 사용하는 디바이스는 더 많은 엔드포인트를 제공합니다.예를 들어 USB MIDI 클래스의 32비트 인코딩을 사용하는 디바이스는 [케이블 식별자(Cable Identifier)]필드를 사용하여 최대 16개의 엔드포인트를 나타낼 수 있습니다.AppleMIDI 세션 프로토콜을 사용할 경우 RTP-MIDI 측에서는 쌍으로 구성된 UDP 포트에 의해 엔드포인트가 표시됩니다.

세션은 두 엔드포인트 간의 연결을 정의합니다.1개의 엔드포인트의 MIDI IN은 리모트엔드포인트의 MIDI OUT에 접속되며 그 반대도 마찬가지입니다.소프트웨어 구성에 따라 단일 엔드포인트가 여러 세션을 받아들일 수 있습니다.특정 엔드포인트의 각 세션은 리모트세션 핸들러의 단일 세션으로 표시됩니다.리모트 세션핸들러는 접속처의 엔드포인트가 다른 세션에서 동시에 사용되고 있는지 여부를 인식하지 않습니다.특정 엔드포인트에 대해 여러 세션이 활성화되어 있는 경우 해당 엔드포인트에 도달하는 다른 MIDI 스트림은 MIDI 데이터가 응용 프로그램으로 전송되기 전에 병합됩니다.다른 방향에서는 응용 프로그램에 의해 생성된 MIDI 데이터가 엔드포인트에 연결된 모든 세션핸들러로 송신됩니다.

Apple MIDI 세션 참가자

Apple MIDI 실장에서는 세션 발신측과 세션청취자의 2종류의 세션컨트롤러를 정의합니다.세션 발신측은 세션청취자의 초대를 담당하며 클럭 동기 시퀀스를 담당합니다.세션 이니시에이터는 일반적으로 세션청취자가 될 수 있지만 iOS 디바이스 등 일부 디바이스는 세션청취자만 될 수 있습니다.

MIDI 머지

"MIDI 병합"이 필요한 MIDI 1.0 디바이스와는 달리 RTP-MIDI 디바이스는 특정 컴포넌트를 필요로 하지 않고 서로 다른 MIDI 스트림을 병합할 수 있습니다.그림에서 알 수 있듯이 세션컨트롤러가 2개 이상의 리모트세션에 접속되면 리모트디바이스에서 발신되는 MIDI 스트림이 자동으로 Marge 됩니다.특정 설정은 필요 없습니다.

MIDI 분할("MIDI ThRU")

RTP-MIDI 디바이스는 MIDI 스트림을 1개의 세션에서 임의의 수의 리모트세션으로 복제할 수 있으며 'MIDI THRU' 지원 디바이스는 필요 없습니다.RTP-MIDI 세션이 2개 이상의 리모트세션에 접속되어 있는 경우, 모든 리모트세션은 송신원으로부터 송신된 MIDI 데이터의 카피를 수신합니다.

분산 패치 베이 개념

또한 RTP-MIDI 세션은 "패치베이" 기능을 제공할 수 있습니다.패치베이에는 MIDI 1.0 접속을 가진 별도의 하드웨어 디바이스가 필요합니다.MIDI 1.0 패치베이는 MIDI 입력 세트와 MIDI 출력 세트 간에 대부분의 경우 매트릭스 형태로 동적으로 연결할 수 있는 하드웨어 장치입니다.「다이나믹」접속이라는 개념은, 케이블을 2개의 디바이스간에 「정적」으로 접속하는 종래의 MIDI 1.0 회선과는 대조됩니다.패치베이는 케이블 형태로 디바이스 간에 데이터 경로를 확립하는 것이 아니라 모든 MIDI 디바이스가 연결되는 중앙 지점이 됩니다.MIDI 패치베이의 소프트웨어는 어떤 MIDI 입력이 어떤 MIDI 출력으로 전송되는지 정의하도록 구성되어 있으며 사용자는 MIDI DIN 케이블을 분리하지 않고도 언제든지 이 설정을 변경할 수 있습니다.

세션 개념 덕분에 RTP-MIDI에서는 "patchbay" 하드웨어 모듈이 더 이상 필요하지 않습니다.세션은 정의상 2개의 MIDI 포트 간에 네트워크를 통해 확립되는 가상 경로입니다.설정 프로세스는 특정 MIDI 디바이스에 의해 생성되는 각 MIDI 스트림의 수신처를 정확하게 정의하기 때문에 패치베이 기능을 수행하기 위해 특정 소프트웨어가 필요하지 않습니다.그 후, 각 세션의 개시자가 사용하는 행선지 IP 주소를 변경하는 것만으로, 이러한 가상 패스를 언제라도 변경할 수 있습니다.이와 같이 형성된 "패치" 구성은 비휘발성 메모리에 저장하여 셋업 시 패치가 자동으로 갱신되도록 할 수 있습니다.단, RTP-MIDI Manager 소프트웨어 툴이나 RTP-MIDI 드라이버 제어판을 사용하여 RAM 수준에서 직접 변경할 수도 있습니다.

'분산 패치베이'라는 용어는 다른 RTP-MIDI 디바이스가 전체 MIDI 셋업 전체에 지리적으로 분산될 수 있는 반면 MIDI 1.0 패치베이는 다른 MIDI 디바이스를 패치베이 디바이스 자체에 직접 배치하도록 강제했기 때문입니다.

애플의 세션 프로토콜

RFC6295 문서에서는 RTP-MIDI 파트너 간의 세션을 확립 및 관리하기 위해 SDP(Session Description Protocol) 및 SIP(Session Initiation Protocol) 프로토콜을 사용할 것을 제안하고 있습니다.그러나 이 두 개의 프로토콜은 특히 RTP 헤더와 RTP-MIDI 페이로드 모두에서 타이밍 데이터와 관련된 모든 필드를 차례로 정의하는 샘플링 주파수처럼 세션 기술자에 열거된 어떤 매개 변수도 제한하지 않기 때문에 작은 시스템에서 구현하기에는 매우 무겁습니다.또한 RFC6295 문서에서는 이러한 프로토콜을 사용하도록 권장할 뿐이므로 다른 프로토콜을 사용할 수 있으므로 공급업체 간에 비호환성이 발생할 수 있습니다.

애플은 자체 프로토콜을 만들어 샘플링 주파수와 같은 동기 관련 모든 매개변수를 적용하기로 했다.이 세션 프로토콜은 Wireshark 소프트웨어에서 "AppleMIDI"라고 합니다.AppleMIDI 프로토콜을 사용한 세션 관리에는 두 개의 UDP 포트가 필요합니다. 첫 번째 포트는 "Control Port"이고 두 번째 포트는 "Data Port"입니다.멀티스레드 구현 내에서 사용할 경우 데이터 포트만 "실시간" 스레드를 필요로 하며 다른 포트는 일반 우선 스레드로 제어할 수 있습니다.이들 2개의 포트는 2개의 연속된 로케이션(n/n+1)에 배치해야 합니다.첫 번째 포트는 65536 중 하나의 포트입니다.

Apple MIDI 프로토콜을 사용하여 UDP 포트 세트에서 동시에 열 수 있는 세션 수에 제약은 없습니다.세션 매니저별로 1개의 포트 그룹을 작성할 수도 있고 여러 세션에 1개의 그룹만 사용할 수도 있습니다.이것에 의해, 시스템의 메모리 용량이 제한됩니다.이 마지막 예에서는 IP 스택이 파트너를 IP 주소와 포트 번호로 식별하는 리소스를 제공합니다.이 기능은 "소켓 재사용"이라고 불리며 대부분의 최신 IP 구현에서 사용할 수 있습니다.

모든 Apple MIDI 프로토콜 메시지는 32비트의 4단어로 구성된 공통 구조를 사용합니다.헤더는 값이 255인 2바이트를 포함하며, 그 뒤에 메시지의 의미를 설명하는 2바이트가 있습니다.

묘사	Wireshark 헤더 정의	필드 값(16진수)	필드 값(chars)
초대	APPLEMIDI_COMMAND_INVITATION	0x494e	IN
초대에 응하다	APPLEMIDI_COMMAND_INVITATION_ACCEPTED	0x4f4b	OK
초대를 거부했습니다.	APPLEMIDI_COMMAND_INVITATION_REJECTED	0x4e4f	NO
폐회	APPLEMIDI_COMMAND_ENDSESSION	0x4259	BY
클럭 동기화	APPLEMIDI_COMMAND_SYNCHRONIZATION	0x434b	CK
저널링 동기화	APPLEMIDI_COMMAND_RECEIVER_FEEDBACK	0x5253	RS
비트레이트	APPLEMIDI_COMMAND_BITRATE_RECEIVE_LIMIT	0x524c	RL

이러한 메시지는 각 세션과 관련된 상태 머신을 제어합니다.예를 들어 이 상태 시스템은 세션이 "열린" 상태가 될 때까지 MIDI 데이터 교환을 금지합니다.

초대 시퀀스

세션 오픈은 초대 시퀀스부터 시작합니다.첫 번째 세션 파트너('세션 이니시에이터')는 IN 메시지를 두 번째 파트너의 제어 포트로 보냅니다.세션 개시에 동의하면 OK 메시지를 보내거나 초대를 수락하지 않으면 NO 메시지를 보내 응답합니다.제어 포트에서 초대를 수락하면 데이터 포트에서 동일한 시퀀스가 반복됩니다.양쪽 포트에서 초대가 받아들여지면 스테이트 머신은 동기화 단계로 이행합니다.

동기 시퀀스

동기 시퀀스를 사용하면 양쪽 세션 참가자가 로컬클락에 관한 정보를 공유할 수 있습니다.이 단계에서는 네트워크에 의해 유발되는 지연을 보완할 수 있습니다.또, 「미래의 타임스탬프」도 서포트할 수 있습니다(아래의 「지연」섹션 참조).

세션 이니시에이터는 리모트파트너에게 첫 번째 메시지(CK0이라는 이름)를 송신하여 로컬 시각을 64비트 단위로 나타냅니다(이는 절대 시간이 아니라 로컬 참조와 관련된 시간(일반적으로 운영시스템 커널 시작 후 마이크로초 단위).이 시간은 10kHz 샘플링 클럭 기준으로 표시됩니다(증분당 100마이크로초).리모트 파트너는 이 메시지에 CK1 메시지로 응답해야 합니다.이 메시지에는 64비트의 자체 현지시간이 포함됩니다.그러면 양쪽 파트너는 각각의 클럭의 차이를 알고 RTP-MIDI 프로토콜의 Timestamp 필드와 Deltatime 필드에 적용할 오프셋을 결정할 수 있습니다.

세션 이니시에이터는 CK1 메시지를 수신한 로컬 시간을 포함한 CK2라는 이름의 마지막 메시지를 전송함으로써 이 시퀀스를 종료합니다.이 기술을 통해 네트워크의 평균 지연 시간을 계산할 수 있으며 Linux, Windows 또는 OS X 등의 비실시간 운영 체제에서 발생할 수 있는 느린 시작 스레드로 인해 발생할 수 있는 잠재적인 지연을 보완할 수 있습니다.

동기 정밀도를 높이기 위해 세션 시작 직후에 이 시퀀스를 여러 번 반복할 것을 권장합니다.이는 일시적인 네트워크 과부하 또는 스레드 활성화 지연 피크 때문에 예기치 않게 지연된 경우입니다.

로컬 클럭 드리프트의 보상에 의해 장기 동기 정밀도를 유지하고 통신 파트너의 손실을 검출하기 위해 이 시퀀스는 보통 분당2 ~ 6회, 세션이니시에이터에 의해 항상 반복되어야 합니다.복수의 CK0 메시지에 응답하지 않는 파트너는 리모트파트너가 절단된 것으로 간주합니다.대부분의 경우 세션 이니시에이터는 원격 파트너가 네트워크에 재접속하는 즉시 통신을 자동으로 재정립하기 위해 상태 머신을 "초대" 상태로 전환합니다.일부 구현(특히 개인용 컴퓨터)에서는 경보메시지를 표시하고 사용자에게 새로운 연결 시도와 세션 종료 중 하나를 선택할 수 있습니다.

저널 업데이트

저널링 메커니즘에 의해 MIDI 메시지 손실을 검출할 수 있으며 수신기는 재전송 없이 손실 데이터를 생성할 수 있습니다.저널은 서로 다른 세션 파트너의 "MIDI 이미지"를 다른 순간에 기억합니다.그러나 세션 파트너가 올바르게 수신한 이벤트에 대응하는 저널링 데이터를 메모리에 보관하는 것은 무용지물이다.그 후 각 파트너는 다른 파트너에게 RS 메시지를 주기적으로 전송합니다.RS 메시지는 올바르게 수신된 마지막 시퀀스 번호를 나타냅니다.즉, 2개의 시퀀스 번호 사이에 공백이 없습니다.그 후, 송신자는 필요에 따라서 낡은 저널링 데이터를 포함한 메모리를 해방할 수 있습니다.

세션 파트너 연결 해제

세션 파트너는 언제든지 세션을 종료하도록 요청할 수 있습니다. 그러면 세션이 종료됩니다.이는 BY 메시지를 사용하여 수행됩니다.세션 파트너는 이 메시지를 수신하면 메시지를 발송한 리모트파트너와의 세션을 즉시 닫고 이 세션에 할당된 모든 리소스를 해방합니다.이 메시지는 세션 발신측 또는 세션청취자("초대된" 파트너")가 송신할 수 있습니다.

레이텐시

RTP-MIDI에 관한 가장 일반적인 우려 사항은 주로 IP 스택을 사용하기 때문에 디지털오디오 워크스테이션의 일반적인 우려 사항인 지연 문제에 관한 것입니다.그러나 올바르게 프로그램된 RTP-MIDI 애플리케이션 또는 드라이버는 다른 통신 방법보다 지연 시간이 길지 않음을 쉽게 알 수 있습니다.

또한 RFC 6295에 기재되어 있는RTP-MIDI에는 레이텐시 보정 메커니즘이 포함되어 있습니다.대부분의 플러그인에서 유사한 메커니즘이 발견되어 처리 경로에 추가되는 지연 시간을 호스트에 알릴 수 있습니다.그러면 호스트는 샘플을 플러그인으로 미리 보낼 수 있으므로 샘플이 준비되고 다른 오디오 스트림과 동기화되어 전송됩니다.RF6295에 기재되어 있는 보정 메커니즘은 에 ^[23]기재되어 있는 MIDI 델타타임에 근거한 상대 타임스탬프 시스템을 사용합니다.RTP payload로 전송되는 각 MIDI 이벤트에는 RTP 헤더의 [Timestamp]필드에 정의되어 있는 현재 payload 시간 원본과 관련된 선행 deltatime 값이 있습니다.

다음으로 RTP-MIDI 페이로드 내의 각 MIDI 이벤트를 글로벌클럭과 엄밀하게 동기화할 수 있습니다.동기 정밀도는 RTP-MIDI 세션을 열 때 정의된 클럭소스에 직접 의존합니다.RFC 6295에서는 MIDI 이벤트의 정확한 타임스탬프 샘플을 얻기 위해 오디오샘플링 클락에 근거한 예를 몇 가지 나타냅니다.Windows 또는 KissBox 임베디드 시스템용 rtpMIDI 드라이버와 같은 다른 모든 관련 구현과 마찬가지로 Apple의 RTP-MIDI 구현은 샘플링 오디오 속도가 아닌 10kHz의 고정 클럭 속도를 사용합니다.이러한 실장에서는 모든 MIDI 이벤트의 타이밍 정확도는 100 마이크로초입니다.

송신측 클럭과 수신측 클럭은 세션 시작 시 동기화되며 세션 기간 동안 세션 이니시에이터에 의해 제어되는 정기적인 동기화 사이클에 의해 동기화됩니다.이 메커니즘에는 LAN 어플리케이션에서 볼 수 있는 수백 마이크로초에서 초까지의 지연을 보정하는 기능이 있습니다.예를 들어 인터넷에 의해 도입된 지연 시간을 보완하여 실시간으로 음악을 실행할 수 있습니다.

단, 이 메커니즘은 주로 시퀀서 트랙에서 나오는 MIDI 스트림과 같이 미리 기록된 MIDI 스트림용으로 설계되었습니다.RTP-MIDI가 실시간애플리케이션(예를 들어 RTP-MIDI 호환 키보드에서 디바이스를 제어)에 사용되는 경우, deltime은 대부분 특정 값 0으로 설정됩니다.즉, 관련 MIDI 이벤트는 수신 즉시 해석됩니다.이러한 사용 예에서는 앞에서 설명한 지연 보상 메커니즘을 사용할 수 없습니다.

얻을 수 있는 지연은 RTP-MIDI 디바이스 간의 통신 경로에 관여하는 다양한 네트워킹컴포넌트와 직접 관련되어 있습니다.

• MIDI 신청 처리 시간
• IP 통신 스택 처리 시간
• 네트워크 스위치/라우터 패킷 전송 시간

신청 처리 시간

MIDI 태스크는 대부분 실시간 태스크이기 때문에 애플리케이션 처리 시간은 일반적으로 엄격하게 제어됩니다.대부분의 경우 지연 시간은 특정 운영 체제에서 얻을 수 있는 스레드 지연 시간(일반적으로 Windows 및 Mac OS 시스템에서 최대 1~2ms)에서 직접 발생합니다.실시간 커널을 탑재한 시스템은 최대 100마이크로초까지 훨씬 더 나은 결과를 얻을 수 있습니다.처리 스레드는 통신 관련 스레드/태스크와는 다른 수준에서 동작하기 때문에 이 시간은 통신 채널(MIDI 1.0, USB, RTP-MIDI 등)에 관계없이 일정하다고 간주할 수 있습니다.

IP 스택 처리 시간

통신 프로세스가 운영체제 제어 하에 있기 때문에 IP 스택 처리 시간이 가장 중요합니다.이는 Windows, Mac OS 또는 Linux를 포함한 대부분의 운영체제는 이더넷어댑터에 대한 직접 접근을 허용하지 않기 때문에 IP 관련 통신 프로토콜에 관계없이 적용됩니다.특히 raw sockets와 direct access to network를 혼동하는 경우가 많습니다.대부분의 operating system에서는, 소켓이 네트워크를 개입시켜 데이터를 송수신 하는 엔트리 포인트입니다."raw socket"은 응용 프로그램이 모든 프로토콜을 사용하여 패킷을 전송할 수 있도록 하는 소켓입니다.그러면 애플리케이션은 주어진 프로토콜 규칙에 따라 전보를 작성할 책임이 있는 반면, "직접 액세스"는 운영 체제 커널로 제한된 시스템 수준의 액세스를 필요로 합니다.네트워크 어댑터가 현재 다른 애플리케이션에서 사용되고 있는 경우는, raw 소켓을 사용해 송신된 패킷이 operating system에 의해서 지연되는 일이 있습니다.따라서, IP 패킷은, 원시 소켓에 관련하는 패킷보다 먼저 네트워크에 송신할 수 있습니다.엄밀히 말하면, 특정의 네트워크 카드에의 액세스는 「세마포」^[25]에 의해서 제어됩니다.

IP 스택은 ARP라는 특정 프로토콜을 사용하여 이더넷주소(MAC 주소)와 IP 주소를 관련지어야 합니다.RTP-MIDI 애플리케이션이 리모트디바이스에 패킷을 송신하는 경우, 라우터/스위치간에 전송 패스를 작성하기 위해서, 이더넷은 IP 관련의 개념을 이해하지 않기 때문에, RTP-MIDI 애플리케이션은 최초로 네트워크상에서 패킷을 검출할 필요가 있습니다.이것은 IP 스택에 의해 최초로 ARP(Address Recognition Protocol) 요구를 전송함으로써 자동으로 실행됩니다.행선지 디바이스는, ARP 패킷내의 자신의 IP 주소를 인식하면, MAC 주소를 포함한 ARP 응답을 반환합니다.IP 스택은, RTP-MIDI 패킷을 송신할 수 있습니다.다음 RTP-MIDI 패킷은 링크가 몇 분간 비활성화되어 송신측 라우팅 테이블의 ARP 엔트리가 클리어 되지 않는 한 ARP 시퀀스를 필요로 하지 않게 됩니다.

이 ARP 시퀀스에는 몇 초가 걸릴 수 있습니다.그 결과 적어도 첫 번째 RTP-MIDI 패킷에서는 상당한 지연이 발생할 수 있습니다.그러나 애플의 구현은 세션 제어 프로토콜을 사용하여 이 문제를 우아하게 해결했습니다.세션 프로토콜은 RTP-MIDI 프로토콜 자체와 동일한 포트를 사용합니다.다음으로 ARP 시퀀스는 세션 시작 시퀀스 중에 발생합니다.RTP-MIDI 애플리케이션이 최초의 RTP-MIDI 패킷을 송신하는 경우, 컴퓨터의 라우팅 테이블은 올바른 행선지 MAC 주소로 이미 초기화되어 있기 때문에, 최초의 패킷의 지연은 회피됩니다.

ARP 시퀀스 외에 IP 스택 자체에서는 IP 헤더, UDP 헤더, RTP 헤더 등의 패킷헤더를 준비하기 위한 계산이 필요합니다.최신 프로세서를 사용하면 이 준비는 매우 빠르고 몇 마이크로초밖에 걸리지 않습니다. 이는 애플리케이션 지연 시간 자체에 비해 무시할 수 있는 수준입니다.앞서 설명한 바와 같이 RTP-MIDI 패킷은 준비되면 소켓이 IP 패킷인지 "raw" 패킷인지에 관계없이 어댑터가 이미 다른 패킷을 전송하고 있는 경우 네트워크 어댑터에 도달하려고 할 때만 지연될 수 있습니다.그러나 네트워크 어댑터를 담당하는 드라이버 스레드의 우선순위가 매우 높기 때문에 이 수준에서 발생하는 지연 시간은 일반적으로 매우 낮습니다.또, 대부분의 네트워크 어댑터는 하드웨어 레벨의 FIFO 버퍼를 갖추고 있기 때문에, 드라이버 스레드를 최초로 실행할 필요 없이, 네트워크 어댑터 자체에 패킷을 보존해 즉시 송신할 수 있습니다.「어댑터 액세스 경합」에 관련하는 지연 시간을 가능한 한 짧게 하는 방법은, 네트워크 어댑터를 MIDI 통신 전용으로 예약해, 파일 공유나 인터넷 브라우징등의 다른 네트워크 용도로 다른 네트워크 어댑터를 사용하는 것입니다.

네트워크 컴포넌트 라우팅 시간

사용되는 프로토콜이 무엇이든 간에 컴퓨터 간에 이더넷 패킷을 전송하는 데 사용되는 다른 구성 요소도 지연을 유발합니다.최신 네트워크 스위치는 모두 "Store and Forward" 기술을 사용합니다.이 테크놀로지는 패킷이 다음 스위치로 전송되기 전에 스위치에 저장됩니다.단, 대부분의 경우 스위칭 시간은 무시할 수 있습니다.예를 들어 100Mbit/s 네트워크상의 64바이트 패킷은 각 네트워크 스위치에 의해 전송되는 데 약 5.1마이크로초가 걸립니다.특정 경로 상에 10개의 스위치가 있는 복잡한 네트워크에서는 51마이크로초의 지연이 발생합니다.

단, 스위치에서는 패킷이 전송될 때까지 지연되기 때문에 지연은 네트워크 부하 자체에 직접 관련되어 있습니다.네트워크 컴포넌트에 의해 발생하는 실제 레이텐시의 계산/측정은 어려운 작업이 될 수 있습니다.예를 들어, 같은 네트워크 스위치에 접속되어 있는2대의 네트워크 디바이스간의 레이텐시를 측정하면, 항상 뛰어난 결과를 얻을 수 있습니다.앞서 설명한 바와 같이 네트워크컴포넌트에 의해 발생하는 지연을 제한하는1가지 솔루션은 개별 네트워크를 사용하는 것입니다.그러나 이는 컴퓨터의 네트워크 어댑터보다 네트워크 구성 요소에 훨씬 덜 중요합니다.

실시간 어플리케이션의 예상 레이텐시

알 수 있듯이 RTP-MIDI 링크에 대해 얻을 수 있는 정확한 지연은 많은 파라미터에 의존하며 이들 대부분은 운영시스템 자체에 관련되어 있습니다.다른 RTP-MIDI 액터에 의한 측정은 실시간 운영체제를 사용하는 임베디드 시스템의 경우 수백 마이크로초에서 범용 운영체제를 실행하는 컴퓨터의 경우 최대 3밀리초의 지연시간을 제공합니다.

레이텐시 확장(밀리초 미만의 레이텐시)

AES는 2010년에 매우 낮은 레이텐시 어플리케이션에서 IP 네트워크에서 RTP payload를 사용하는 기능을 증명하기 위해 SC-02-12H라는^[26] 이름의 작업 그룹을 시작했습니다.이 그룹이 2013년 5월에 발표한 제안서 초안에서는 125마이크로초의 낮은 지연 시간으로 라이브 애플리케이션을 위한 RTP 스트리밍이 가능하다는 것을 보여줍니다.

배열

RTP-MIDI와 관련된 다른 가장 일반적인 문제는 설정 프로세스입니다.이것은, 디바이스에 의한 네트워크에의 물리적인 접속만으로는, 다른 디바이스와의 통신을 보증할 수 없기 때문입니다.RTP-MIDI는 IP 프로토콜 스택에 기반하므로 IP 주소 및 UDP 포트 등 통신 프로세스에 관련된 여러 계층을 설정해야 합니다.이 설정을 심플화하기 위해 다양한 솔루션이 제안되고 있습니다.가장 일반적인 것은 제로 컨피규레이션(Zero Configuration) 테크놀로지 세트입니다.

RFC 3927 에서는, IP 주소를 자동적으로 할당하는 일반적인 방법에 대해 설명하고 있습니다.이 방법은 대부분의 RTP-MIDI 호환 제품에서 사용됩니다.IP 네트워크에 접속하면, 이러한 디바이스는 자동적으로 IP 주소의 경합을 해결하면서, IP 주소를 할당할 수 있습니다.디바이스가 RTP 사양의 포트 할당 권장 사항을 따를 경우 네트워크 관점에서 디바이스는 "플러그 앤 플레이"가 됩니다.그 후, IP 주소나 UDP 포토 번호의 정의 없이, RTP-MIDI 네트워크 전체를 작성할 수 있습니다.단, 이러한 방식은 일반적으로 소규모 셋업용으로 예약되어 있습니다.Zeroconf 시스템에 의해 선택된IP 주소와 디바이스의 물리적인 위치 사이에는 직접적인 관계가 없기 때문에 장애가 있는 디바이스의 현지화가 복잡해질 수 있기 때문에 대규모 셋업에서는 네트워크 설정의 완전한 자동화는 일반적으로 회피됩니다.그 후, 네트워크에 접속하기 전에 디바이스에 이름을 할당하는 것이 최소한의 설정입니다.이 경우, 「진정한 플러그 앤 플레이」의 개념은 무효가 됩니다.

'제로 구성' 개념은 네트워크 통신 계층에 한정되어 있다는 점에 유의해야 합니다.어드레싱 레이어를 추상화하는 것만으로 네트워크 디바이스(MIDI 관련 여부에 관계없이)의 완전한 설치를 실행하는 것은 기술적으로 불가능합니다.이 제한을 나타내는 실용적인 사용 예로는 RTP-MIDI 인터페이스에 연결된 MIDI 마스터키보드를 사용하여 제어해야 하는 RTP-MIDI 사운드제너레이터가 있습니다.사운드 제너레이터와 MIDI 인터페이스가 '제로 구성' 서비스를 통합하더라도 IP 구성 서비스는 서로 다른 수준에서 동작하기 때문에 세션을 함께 확립할 필요가 있음을 스스로 알 수 없습니다.네트워크화된 MIDI 시스템은 (IP 기반 여부에 관계없이) MIDI 데이터 교환에 사용되는 프로토콜에 관계없이 필수 구성 도구를 사용하여 네트워크에 연결된 후 디바이스 간에 수행해야 하는 교환을 정의해야 합니다.이 구성 도구는 컴퓨터에서 실행되는 외부 관리 도구가 될 수도 있고, 장치가 휴먼-머신 인터페이스를 통합하는 경우 구성 메뉴 형식으로 장치의 응용 프로그램 소프트웨어에 내장될 수도 있습니다.

MIDI 2.0과의 호환성

MIDI Manufacturers Association(MIDI 제조업체 협회)은 2019년^[28] 1월 MIDI 2.0이라는 MIDI 프로토콜의 주요 진화가 최종 프로토타이핑 단계에 접어들었다고 발표했습니다.

MIDI 2.0은 프로토콜 협상에 사용되는 MIDI-CI 확장에 크게 의존합니다(프로토콜 전환이 가능하도록 MIDI 1.0 및 MIDI 2.0 장치 식별).RTP-MIDI는 MIDI 2.0 디바이스에서도 MIDI 1.0 System Exclusive를 사용하기 때문에 MIDI-CI 프로토콜을 완전히 지원합니다.

MIDI 2.0을 포함하는 RTP-MIDI 프로토콜의 진화가 MMA에 제시되었으며 현재 MIDI 2.0 작업 그룹에서 논의되고 있습니다.확장 프로토콜은 MIDI 1.0 및 MIDI 2.0 데이터 형식을 병렬로 지원합니다(MIDI 2.0은 32비트 기반 패킷을 사용하며 MIDI 1.0은 8비트 기반 패킷을 사용합니다).

RTP-MIDI를 사용하는 기업/프로젝트

• Apple Computer (RTP-MIDI 드라이버는 Mac OS X 및 iOS에 내장되어 있으며, 이더넷 및 WiFi를 통한 RTP-MIDI)
• 야마하(Motif 신시사이저, UD-WL01 어댑터^[29]) - 이더넷 및 WiFi를 통한 RTP-MIDI
• 베링거(X-Touch 제어면)^[30]
• KissBox (RTP-MIDI 인터페이스와 MIDI 1.0, LTC, I/O 및 ArtNet, 하드웨어 신시사이저 리모트 컨트롤용 VST 플러그인)
• Tobias Erichsen Consulting (Windows/유틸리티용 무료 RTP-MIDI 드라이버)
• GRAME(Linux 드라이버)
• HRS(이더넷/동기 소프트웨어 상에서의 MIDI 타임코드 배포)
• iConnectivity(USB 및 RTP-MIDI 지원 오디오 및 MIDI 인터페이스)
• Marge Technologies(Horus, Hapi, Pyramix, Attoption) - LTC/MTC, MIDI DIN 및 MicPre 제어용 RTP-MIDI
• Zivix PUC(iOS ^[32]디바이스용 무선 RTP-MIDI 인터페이스)
• Arduino-AppleMIDI-라이브러리^[33]
• MIDIbox^[34]
• Cinara (USB 및 RTP-MIDI를 ^[35]지원하는 MIDI 인터페이스)
• Linux용^[36] McLaren Labs rtpmidi
• BEB(RTP-MIDI ^[37]백본에 기반한 모듈러 신시사이저용 DSP 모듈)
• Axoloti(RTP-MIDI ^[38]연결을 갖춘 하드웨어 오픈 소스 신시사이저)

레퍼런스