A tool for each part of the work
The MODAVIS ecosystem separates research responsibilities while connecting the resulting evidence.
From fieldwork to publication
Recording, reconciliation, analysis and interactive presentation ask different things of a tool. MODAVIS treats them as connected stages with explicit inputs, outputs and responsibilities.
Six core components organize the research workflow. Monitor and the musiXplora Bridge provide supporting capabilities. Twelve Processor modules and specialist applications handle particular transcription, analysis, modelling and presentation tasks.
Where does an extracted number become an accepted claim?
A processing candidate is a proposed interpretation of source material. Review and publication are additional decisions, with their own evidence and responsibilities.
Work through the example 3 STEPS
Use the Cuntz workbook observation to imagine a new import workflow. This is an explanatory mapping to the Processor architecture, not a claim that the published Cuntz release was built by all current Processor modules.
Preserve the source
Intake identifies the workbook bytes and source context. Extraction retains the literal cell, property code and unit rather than keeping only a convenient normalized number.
Inspect the candidate
A normalizer can propose a structured observation and a pipe identity. A reviewer checks the cell interpretation, the identity match and qualifications such as the timestamp note.
Publish the accountable result
An accepted projection keeps the evidence link and decision. A public view can be concise while a fixed release preserves the record needed to re-examine the claim.
- Cuntz Positiv · VAO 0.5.0-rc.2 ↗
Published manifest: identities, measurement observations, realization digests, profiles and rights. Exact examples checked against this release.
- MODAVIS Ontology Network 0.1.0 ↗
Identity, state, configuration, evidence, assertions, context and provenance. Teaching examples explain its distinctions without inventing new normative properties.
The example illustrates component responsibilities without attributing unverified processing history to the actual release.
The useful distinction. Automation can propose a useful structure; an accountable workflow keeps the interpretation and its grounds inspectable.
Start with an outcome
| You want to… | Start with… | Then keep… |
|---|---|---|
| Explore instruments and their sources | Navigator or OrgMap | Record identities, source references and dataset version. |
| Document a recording session | OrgRec | Original takes, configuration and review decisions. |
| Review photographed text | Scriptor | Source crops, raw transcription and corrections. |
| Inspect a VAO package | VAO CLI or a compatible viewer | Package version, capabilities and verification result. |
| Build a Unity or Blender workflow | The corresponding VAO importer | The importer version and the supported contract. |
| Reuse an analytical corpus | A fixed dataset or research collection | Distribution, checksum and method. |
These entry points serve different audiences. Public viewers offer immediate exploration. Desktop applications and importers require an appropriate local environment. The framework’s backend components organise research processing under controlled operation; they are not public upload endpoints that a visitor is expected to discover or configure.
Read three versions separately
A software version identifies an implementation, a standard version identifies a contract, and a data version identifies an input or object release. A demonstration may combine one of each. Write down all three when reporting a result or a problem: “the latest tool” is not enough to reproduce what happened.
From a demonstration to reuse
A demonstration shows a particular configuration working under particular conditions. Before adapting it, inspect the input assumptions, supported platform and documented output. This is especially important for research modules whose results need review, or whose scope is narrower than a familiar product label suggests. The directory’s expanded entries describe the practical role and the interpretation boundary together.
Sources & further reading
- Dominik Ukolov · Musikinstrumente im virtuellen Raum (2026)
Dissertation submitted to Universität Leipzig, 11 September 2026. Chapters 1–6 and 8; Appendix I.4 for the software and resource inventory. See the dedicated research guides for claim-specific section references. Page numbers refer to the printed manuscript pagination. The manuscript is not distributed by this website.
- OrgRec 0.3.2
The recording application’s release record.
- MODAVIS on Zenodo
Research data, software and publications.
Page editions 2026-09-r6 ↓
Read a fixed snapshot of this chapter, or return to the current notebook.
0ef9441a7880Page metadata ↗