Incorporating MIDI 2 into your apps
At a glance
| Item | Summary |
|---|---|
| Purpose | Add precision and improve musical control for your MIDI apps. |
| App architecture | A C/Objective-C header, Objective-C++, Swift sample with the source-visible chain MIDIReceiverApp → PacketReceiverView → MIDIEndpointManager → MIDIAdapter → CoreMIDI APIs. |
| Main patterns | Adapter, Publisher-backed observable state |
| Project style | 36 scanned source file(s) across C/Objective-C header, Objective-C++, Swift, organized around ranked entry, type, and file boundaries. |
Project structure
Source bundle/
└── UniversalMIDIPacket/
├── UMP Receiver/
│ ├── MIDIReceiverApp.swift
│ └── Views/
│ └── PacketReceiverView.swift
├── UMP Send/
│ ├── MIDISendApp.swift
│ ├── Views/
│ │ ├── Builder/
│ │ │ └── PacketBuilderView.swift
│ │ ├── Inspector/
│ │ │ └── PacketChunkView.swift
│ │ └── PacketSenderView.swift
│ └── Models/
│ ├── MIDIEndpointManager.swift
│ └── PacketModel.swift
└── Shared/
├── Models/
│ ├── LogModel.swift
│ └── MIDIEndpointModel.swift
├── Views/
│ └── LogView.swift
└── Realtime/
└── MIDIAdapter.h
Structure observations
- Architecturally prominent files are ranked from entry points and role-named declarations; resource-only paths are omitted.
- Primary languages: C/Objective-C header, Objective-C++, Swift.
- The verified tree contains 7 project/configuration file(s) and 35 source declaration(s).
Overall architecture
flowchart LR
N1["MIDIReceiverApp"]
N2["PacketReceiverView"]
N3["MIDIEndpointManager"]
N4["MIDIAdapter"]
N5["CoreMIDI APIs"]
N1 --> N2
N2 --> N3
N3 --> N4
N4 --> N5
Reference code
UniversalMIDIPacket/UMP Receiver/MIDIReceiverApp.swift:10 — architecture anchor
@main
struct MIDIReceiverApp: App {
// ...
}Interpretation
The arrows summarize the source-visible entry, role-named types or folders, and framework direction; when nodes come from structural folders, the sequence is a high-level interpretation rather than proof that every adjacent node calls the next. Ownership is claimed only where the next section cites a stored property or assignment. The diagram is intentionally limited to the dominant path into Core MIDI.
Ownership and state
classDiagram
MIDIReceiverApp *-- AppState : appState
MIDIReceiver *-- AppState : appState
PacketReceiverView o-- ReceiverOptions : receiverOptions
PacketReceiverView o-- LogModel : logModel
Ownership evidence
UniversalMIDIPacket/UMP Receiver/MIDIReceiverApp.swift:13 — stored dependency or nearest verified ownership anchor
@main
struct MIDIReceiverApp: App {
// ...
private var appState = AppState()
// ...
}| Owner | Object or state | Relationship | Mutation authority |
|---|---|---|---|
MIDIReceiverApp |
AppState (appState) |
creates and retains | Owning lexical scope |
MIDIReceiver |
AppState (appState) |
creates and retains | Owning lexical scope |
PacketReceiverView |
ReceiverOptions (receiverOptions) |
observes externally owned state | The observed object is authoritative |
PacketReceiverView |
LogModel (logModel) |
observes externally owned state | The observed object is authoritative |
Composition arrows indicate a source-visible construction expression or locally owned value state; aggregation means the owner stores or receives a dependency without proving exclusive lifetime ownership.
Class and protocol design
UniversalMIDIPacket/UMP Receiver/MIDIReceiverApp.swift:11 — representative type boundary
struct MIDIReceiverApp: App {
// ...
}| Type | Responsibility | Depends on or conforms to |
|---|---|---|
MIDIReceiverApp |
Application entry and top-level composition | App |
PacketReceiverView |
User-interface presentation and input forwarding | View |
DestinationTextView |
User-interface presentation and input forwarding | View |
DestinationProtocolView |
User-interface presentation and input forwarding | View |
PacketBuilderView |
User-interface presentation and input forwarding | View |
PacketChunkView |
User-interface presentation and input forwarding | View |
LogModel |
Feature data or observable state | ObservableObject |
MIDIEndpointModel |
Feature data or observable state | Identifiable |
MIDIEndpointManager |
Long-lived feature or framework coordination | Identifiable, ObservableObject |
PacketModel |
Feature data or observable state | Identifiable, ObservableObject |
No local protocol conformance is claimed as protocol-oriented design; external framework conformances are listed only as dependencies.
Access control
| Symbol | Access | Verified effect | Likely rationale |
|---|---|---|---|
description (UniversalMIDIPacket/Shared/Extensions/MIDIEventPacketExtensions.swift:13) |
public |
The symbol is visible to importing modules. | Inference: make the declaration available across a module or target boundary. |
description (UniversalMIDIPacket/Shared/Extensions/MIDIEventPacketExtensions.swift:85) |
public |
The symbol is visible to importing modules. | Inference: make the declaration available across a module or target boundary. |
description (UniversalMIDIPacket/Shared/Extensions/MIDIProtocolIDExtensions.swift:11) |
public |
The symbol is visible to importing modules. | Inference: make the declaration available across a module or target boundary. |
appState (UniversalMIDIPacket/UMP Receiver/MIDIReceiverApp.swift:13) |
private |
Use is restricted to the lexical declaration and same-file extensions allowed by Swift. | Inference: keep state mutation or dependency lifetime inside the owning implementation. |
Reference code
UniversalMIDIPacket/Shared/Extensions/MIDIEventPacketExtensions.swift:13 — representative boundary
public var description: String {
// ...
}Swift declarations without a modifier are internal; explicit private, fileprivate, private(set), public, or open entries above are interpreted by language semantics. Objective-C/C samples instead rely on header and implementation boundaries, which are not equivalent to Swift lexical privacy.
Logic ownership and placement
| Logic | Owning type or file | Placement rationale |
|---|---|---|
| Translates one interface or representation into another | MIDIAdapter |
The source’s Adapter suffix makes this role explicit. |
| Application entry and top-level composition | MIDIReceiverApp |
The source’s App suffix makes this role explicit. |
| Long-lived feature or framework coordination | MIDIEndpointManager |
The source’s Manager suffix makes this role explicit. |
| Feature data or observable state | LogModel, MIDIEndpointModel, PacketModel |
The source’s Model suffix makes this role explicit. |
| User-interface presentation and input forwarding | DestinationProtocolView, DestinationTextView, DynamicChunkView, LogView |
The source’s View suffix makes this role explicit. |
Design patterns
| Pattern | Source evidence | Purpose or tradeoff |
|---|---|---|
| Adapter | UniversalMIDIPacket/Shared/Realtime/MIDIAdapter.h:13 |
An adapter-named type translates interfaces or representations. |
| Publisher-backed observable state | UniversalMIDIPacket/Shared/Models/LogModel.swift:12 |
Published properties notify observers while mutation remains with the state object. |
Naming conventions
- Types: Adapter: MIDIAdapter; App: MIDIReceiverApp; Manager: MIDIEndpointManager; Model: LogModel, MIDIEndpointModel, PacketModel; View: DestinationProtocolView, DestinationTextView, DynamicChunkView, LogView, MIDIDestinationView.
- Protocols: no local protocol declaration in the scanned source.
- Methods:
print,clear,populateDestinations. - Files:
UniversalMIDIPacket/UMP Receiver/MIDIReceiverApp.swift,UniversalMIDIPacket/UMP Receiver/Views/PacketReceiverView.swift,UniversalMIDIPacket/UMP Send/Views/Builder/PacketBuilderView.swift,UniversalMIDIPacket/UMP Send/Views/Inspector/PacketChunkView.swift,UniversalMIDIPacket/Shared/Models/LogModel.swift,UniversalMIDIPacket/Shared/Models/MIDIEndpointModel.swift.
Architecture takeaways
MIDIReceiverAppis the main source-visible entry or composition anchor for this sample.- Framework work reaches SwiftUI, CoreMIDI, CoreGraphics through a deliberately small high-level chain; the detailed API graph remains inside the cited implementation files.
- Stored-property evidence identifies lifecycle collaboration; it does not by itself prove exclusive object ownership.
- Access-control conclusions separate verified language visibility from the likely design rationale.
- The source does not justify labeling the design protocol-oriented.
Source map
| Source file | Relevant symbols |
|---|---|
UniversalMIDIPacket/UMP Receiver/MIDIReceiverApp.swift |
MIDIReceiverApp |
UniversalMIDIPacket/UMP Send/MIDISendApp.swift |
MIDIReceiver |
UniversalMIDIPacket/UMP Receiver/Views/PacketReceiverView.swift |
PacketReceiverView, DestinationTextView, DestinationProtocolView, PacketReceiverView_Previews |
UniversalMIDIPacket/UMP Send/Views/Builder/PacketBuilderView.swift |
ChunkDisplayType, PacketBuilderView, PacketSender_Previews |
UniversalMIDIPacket/UMP Send/Views/Inspector/PacketChunkView.swift |
PacketChunkCell, PacketChunkView, PacketChunkView_Previews |
UniversalMIDIPacket/Shared/Models/LogModel.swift |
LogModel |
UniversalMIDIPacket/Shared/Models/MIDIEndpointModel.swift |
MIDIEndpointModel |
UniversalMIDIPacket/UMP Send/Models/MIDIEndpointManager.swift |
MIDIEndpointManager |
UniversalMIDIPacket/UMP Send/Models/PacketModel.swift |
PacketModel |
UniversalMIDIPacket/Shared/Views/LogView.swift |
LogView, LogView_Previews |