Choose a VAO client
Match the task, implementation version and declared package capabilities before moving an object between environments.
“Supports VAO” is only the beginning of a compatibility statement. A client can support a particular contract, offer only selected capabilities, or be designed for a specific runtime. The exchange standard and the application release use independent version numbers. The comparison below records the documented states audited for this notebook edition.
Choose by the operation you need
| Implementation | Primary use | Recorded version boundary |
|---|---|---|
| VAO CLI | DOI resolution, package inspection, bounded retrieval and local materialization. | Archived 0.2.0 targets VAO 0.4; development 0.3.1 supports final 0.4 and 0.5. |
| VAO Importer for Unity | Import into Unity for supported media, control, MIDI and XR workflows. | Archive: 0.6.0-rc.1. Development 0.6.0-rc.4 documents final 0.4 and a pinned 0.5 candidate. |
| VAO Blender | Package validation, inspection and verified embedded GLB materialization. | Published 0.4.0-rc.2 documents final 0.4 and a pinned 0.5 candidate; fuller interaction is a legacy 0.2.2 path. |
| OrgRec | A recording and analysis workflow with VAO export. | Published 0.3.2 provides VAO 0.5 export; consult its own import and export documentation. |
| vaoXR | Browser-based inspection and supported interactive experiences. | Published 0.1.0 is independently versioned; capabilities depend on the package and browser. |
Inspect before attempting playback
- Identify the exact object release and the format contract declared in its manifest.
- Check the client’s own version and supported profiles; distinguish final specifications from pinned candidates.
- Establish which resource groups must be available for the intended operation.
- Verify the required realizations before interpreting an image, model or audio result.
- Retain unsupported-capability messages with the report of what was actually tested.
A client can be useful even when it cannot execute an entire experience. Metadata inspection, file-integrity checking and geometry import are meaningful operations with narrower requirements than sampled playback or XR. The interface should explain the level of support rather than implying that a successful import validates every aspect of the package.
Does showing the organ in 3D mean the VAO is playable?
A profile names a set of requirements for a capability. A client’s support describes what an application can do with the object; the two declarations must be compared.
Work through the example 3 STEPS
The Cuntz manifest declares Core, Dynamic Delivery, Playable, Physical Instrument, Scientific, Multimodal, Spatial and Zenodo Repository profiles under VAO 0.5.0.
Read the object’s declarations
The object contains information for several uses, including physical topology, scientific observations and sampled interaction. These requirements describe the package contract.
State the viewer’s operation
The notebook loads a GLB display derivative and provides camera controls. It does not import the full VAO manifest, evaluate its scientific records or execute its keyboard and stop behavior.
Choose another client when the task changes
To test sampled playback or synchronized controls, choose a client whose documented version supports the relevant format, profiles and resources. Record the tested operation separately from successful visual loading.
- Cuntz Positiv · VAO 0.5.0-rc.2 ↗
Published manifest: identities, measurement observations, realization digests, profiles and rights. Exact examples checked against this release.
- VAO Standard 0.5.0 ↗
The standard contract is separate from the Cuntz dataset content version 0.5.0-rc.2.
No acoustics profile or calibrated acoustic response is inferred from the presence of an organ model.
The useful distinction. A working 3D preview proves that the chosen model can be displayed; it does not establish complete VAO conformance or playability.
A practical compatibility note
Object release and version DOI:
VAO format version:
Client name, version and platform:
Operation tested:
Required profiles and resource groups:
Validation result:
Unsupported capabilities or substitutions:
Output artifacts and checksums:Keep the source package unchanged when testing interchange. A newly materialized carrier or derived project is a separate artifact, even when it refers to the same semantic release. If a runtime needs a conversion, document that conversion and preserve a route back to the exact input.
A loaded package is not necessarily an executed object
The Unity source documentation distinguishes MetadataOnly, SelectedGroups and RuntimeRequired materialization. Those modes describe different local resource states, while the runtime’s supported behavior adds another layer. Preserve unsupported data for inspection where the client provides that capability, and record which operation was actually performed. Features documented in the later source candidate must not be attributed wholesale to the archived 0.6.0-rc.1 release.
For Blender 0.4.0-rc.2, the modern VAO path supports validation, inspection and verified visual materialization. It does not provide modern VAO runtime execution, impulse-response convolution or acoustic simulation. Legacy interaction support belongs to a different format path. This makes Blender useful for checking geometry without presenting it as a complete acoustic player.
Sources & further reading
- VAO Standard 0.5.0
- VAO CLI archive
- Unity importer archive
- VAO Blender archive
- OrgRec 0.3.2
- VAO Unity and VAO Blender · source READMEs
Inspected 26 September 2026. Unity source 0.6.0-rc.4 is a pending candidate, distinct from archive 0.6.0-rc.1; Blender capabilities are bounded to published 0.4.0-rc.2 and its documented legacy path.
Page editions 2026-09-r6 ↓
Read a fixed snapshot of this chapter, or return to the current notebook.
e6383885e8ecPage metadata ↗