MFT is an experimental Python environment for representing music as field-like tensors across symbolic scores, audio-derived descriptors, and generated notation.
The project is not trying to replace notation, MIDI, audio analysis, or composition tools. It is a research and composition workbench between them: a way to ask how musical materials behave when pitch, time, voice, energy, density, roughness, activity, and structure are treated as related fields.
Its creative aim is to provide composers with a practical exploratory tool: one that can take musical sources, translate them into shared representations, reshape and compare their materials, and return the results as scores, sounds, or other musically readable forms.
Current work includes:
- Parse and roundtrip several source formats:
- MIDI
- Humdrum /
**kern - MusicXML / SymbTr-style MusicXML
- coarse audio-derived representations
- Convert parsed musical material into field tensors.
- Export field tensors back to MusicXML.
- Compare symbolic and audio-derived descriptors through a shared tensor contract.
- Run small transformation experiments such as rhythmic skeleton transfer, diminution, smoothing, and corpus-style field operations.
- Generate report artifacts for inspection: MusicXML, metadata, plots, and JSON summaries.
The audio path is intentionally modest at this stage. Some examples use chroma-based transcription as a rough hypothesis, not a faithful transcription system.
Many musical ideas are not only note sequences. They involve density, tendency, register, pulse, attraction, texture, voice behavior, resonance, and motion over time.
MFT explores whether those aspects can be represented in a common computational space without flattening musical identity into a single format. The point is not to make an automatic composer. The point is to build tools for musical experiments that move between analysis, transformation, and generation.
Possible uses include:
- studying how materials change under controlled transformations,
- comparing symbolic and acoustic traces of a piece,
- testing cross-style or cross-corpus operations,
- generating MusicXML sketches from field representations,
- building analysis reports around musical structure and energy.
mft/
alignment/ score/audio alignment helpers
analysis/ structural, harmonic, motif, and tensor analysis utilities
audio/ audio descriptors and rough audio-to-field paths
features/ symbolic, acoustic, dynamic, interaction, and coupling features
generation/ MusicXML, Humdrum, SCAMP, and audio-facing generation helpers
models/ experimental energy/model layers
parsing/ MIDI, MusicXML, Humdrum, SymbTr, and tensor parsers
transforms/ field operations such as projection, morphing, steering, diminution
unified/ shared descriptor contract and cross-source projections
validation/ formal checks and regression-style validation
scripts/ command-line entry points
specs/ YAML configs for experiments
tests/ pytest coverage
docs/ focused notes on roundtrips and Humdrum import
reports/ generated examples and inspection artifacts
Python 3.10+ is recommended.
git clone git@github.com:ayk-caglayan/mft.git
cd mft
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txtMain dependencies include PyTorch, music21, librosa, NumPy, SciPy, matplotlib, Plotly, lxml, pretty_midi, soundfile, PyYAML, and SCAMP.
pytest -qFor focused roundtrip tests:
pytest tests/test_format_roundtrips.py -qThe repo includes scripts for generating self-contained roundtrip folders:
python scripts/generate_format_roundtrips.pyThis creates or refreshes:
reports/format_roundtrips/
midi/
krn/
musicxml/
audio/
Each folder contains a source file, derived tensors, metadata, a plot, and an exported MusicXML score.
The symbolic pipeline is roughly:
MIDI / KRN / MusicXML
-> parsed score representation
-> field tensors
-> metadata + plots
-> MusicXML export
The audio path is rougher:
audio
-> audio descriptors
-> approximate field tensors
-> coarse MusicXML hypothesis
See docs/format_roundtrips.md for details.
Humdrum parsing can use a small helper built against humlib.
bash scripts/build_humlib.shThen run:
python scripts/corpus_to_fields.py humdrum \
--file data/Jos0302b-Missa_Da_pacem-Gloria-A.krn \
--out reports/jos0302b_roundtrip_humlib/
python scripts/fields_to_musicxml.py \
--fields reports/jos0302b_roundtrip_humlib/ \
--out reports/jos0302b_roundtrip_humlib/export.musicxmlSee docs/humdrum_import.md.
One current experiment combines a Josquin/JRP **kern source with a
SymbTr/MusicXML source. It transfers rhythmic skeleton and applies
diminution-style ornamentation while keeping the process inspectable through
tensors, metrics, plots, and MusicXML exports.
python scripts/jrp_symbtr_showcase.py \
--jrp data/Jos0302b-Missa_Da_pacem-Gloria-A.krn \
--symbtr data/hicaz_zirgule--sarki--aksak--alemde_ey--haci_arif_bey.xml \
--config specs/jrp_symbtr_field_ops_short.yaml \
--out reports/jrp_symbtr_showcase_humlibThe result is not presented as a finished composition. It is an analytical/compositional sketch: a way to hear and inspect what happens when materials from different musical worlds are aligned through field operations.
This is an early research codebase.
Some parts are stable enough for repeatable demos and tests. Other parts are prototypes: useful for musical exploration, but not yet a polished library API. Generated MusicXML should be inspected musically. Audio transcription should be treated as approximate unless explicitly validated.
- Keep musical provenance visible.
- Avoid pretending missing data is real data.
- Preserve source-specific information when possible.
- Make transformations inspectable through scores, tensors, plots, and metrics.
- Prefer musically useful experiments over opaque automation.
Add license information here.