Music

Music is organized sound, but the useful compendium definition is wider: music is a practice of time, gesture, notation, performance, recording, listening, metadata, and cultural memory. A song, score, sample, field recording, instrument, DAW session, plugin chain, live visual patch, or release record can all be music-adjacent knowledge objects.

This page connects music to art, design, symbols, language, books, data storage, standards, human-machine interaction, data visualization, Wasm, and Python. The common thread is preservation of meaning across time: a musical idea has to survive bodies, rooms, instruments, files, formats, interfaces, rights, and interpretation.

Music is not only an audio waveform. It can be a performed event, an abstract composition, a notated score, a studio construction, a ritual, a dataset, a record release, a synchronized image, a sample library, or a memory attached to a place and group of people. Each form needs a different record.

The compendium should separate:

• work: the abstract song, composition, cue, set, or improvisational frame;
• expression: arrangement, performance, version, translation, tuning, or orchestration;
• recording: captured audio with date, performers, room, equipment, and mix choices;
• session: editable DAW project, stems, MIDI, samples, plugins, automation, and notes;
• release: mastered files, artwork, identifiers, rights, distribution, and credits;
• performance system: instruments, controllers, routing, visuals, lighting, and recovery path.

That distinction keeps the graph from treating a composition, a YouTube upload, a WAV file, a vinyl pressing, and a live set as the same object.

Music is a bridge topic. It is art when it is listened to as form, memory, ritual, and feeling. It is design when an interface, instrument, notation system, or stage layout makes action legible. It is data storage when irreplaceable recordings, stems, metadata, and rights need to survive obsolete software. It is standards when MIDI, MusicXML, ISRCs, loudness targets, file formats, and web audio APIs make exchange possible.

Music also makes the body visible in a technical system. Latency, timing, monitoring, affordance, and recovery matter because a performer cannot pause the room while debugging. That makes music one of the clearest examples of human-machine interaction under pressure.

Music records often mix evidence types that should not be collapsed:

• audible evidence: the sound itself, including performance, mix, master, room, and medium;
• notational evidence: score, chord chart, tablature, lead sheet, MIDI, or MusicXML;
• technical evidence: session file, plugin chain, sample rate, routing, controller map, and render settings;
• bibliographic evidence: album, edition, catalog number, label, publisher, and release date;
• rights evidence: composer, lyricist, performer, producer, publisher, label, samples, splits, and licenses;
• contextual evidence: venue, scene, ritual, influence, criticism, audience, and later reuse.

The knowledge graph should say which layer supports a claim. A waveform can prove that a sound exists, but it does not prove authorship or clearance. A database entry may identify a recording, but it does not preserve how the session can be rebuilt.

A durable music or audio-visual project record should preserve:

• project title, artist, collaborators, date, location, and rights status;
• work or cue identifiers, alternate titles, version names, and release relationships;
• session format, DAW version, plugin list, sample rate, bit depth, tempo map, meter, and tuning assumptions;
• source recordings, samples, MIDI, stems, mixes, masters, artwork, cue sheets, and release files;
• controller mappings, visual patches, lighting cues, clock source, and live routing when performance is involved;
• licensing, sample clearance, performer credits, ISRCs, ISWCs, publisher data, and distribution notes;
• recovery notes: what can be rebuilt, what is printed, what is approved, and what depends on unavailable tools.

This turns a session into an archive rather than a folder that only opens on one machine.

The modern production stack is layered:

• capture: microphones, interfaces, field recorders, samplers, direct instrument inputs, and phone recordings;
• composition: notation, sketch recordings, loops, clips, MIDI sequencing, pattern writing, and improvisation;
• sound design: synthesis, sampling, modulation, effects chains, spatial processing, and resampling;
• arrangement: sections, transitions, dynamics, orchestration, automation, and silence;
• mixing: gain staging, EQ, compression, saturation, routing, depth, and monitoring translation;
• mastering: final loudness, sequence, spacing, formats, metadata, and delivery targets;
• performance: instruments, controllers, scenes, loops, cues, failover, and room adaptation;
• archival: stems, session files, notes, identifiers, rights, exports, checksums, and backups.

Tools matter, but the graph should not mistake tool choice for musical meaning. A DAW, plugin, instrument, or controller is useful evidence only when it explains how the work was made, performed, preserved, or recovered.

Music work starts with listening discipline. A room does not need to be expensive, but it should make problems audible: obvious speaker placement, repeatable monitoring levels, treated first reflections when possible, and headphones that reveal edits without flattering everything. Reference tracks are most useful when they are loudness-matched and compared for arrangement, tonal balance, depth, transient shape, and low-end management rather than copied as a vibe.

Capture is also documentation. Field recordings, live sets, samples, stems, and project exports should carry useful filenames, dates, locations, rights notes, tempo information, tuning assumptions, and device metadata when available. The same discipline that helps photography stay searchable helps music projects survive across machines, collaborators, and years.

Music tools are unusually sensitive to time. Latency, jitter, clock drift, buffer size, MIDI mapping, controller feel, and monitoring delay can change the performance even when the audio engine is technically working. A musician is not only using software; they are playing an interface.

This links music to human-machine interaction, industrial products, and design. Knobs, pads, faders, screens, pedals, footswitches, sustain behavior, haptic feel, and shortcuts all become part of the instrument. A good interface lets the performer stay inside the musical task while still exposing enough state to recover.

Notation is a compression system. Staff notation, chord symbols, Nashville numbers, tablature, MIDI piano rolls, percussion notation, figured bass, solfege, cue sheets, and informal rehearsal notes all preserve different parts of a musical idea. None is complete. A score may preserve pitch and rhythm while leaving timbre, swing, room, gesture, and production style to convention.

That makes music a practical branch of symbols and language. A notation mark works only when the performer, software, or reader knows the convention. The graph should distinguish a visual sign from the musical action it denotes, especially when the same symbol changes meaning across genres, instruments, or software.

Audio-visual work turns sound into image, light, movement, or environment. Audio-reactive visuals often map amplitude, frequency, onset, tempo, control voltage, MIDI, spectral features, or performer gestures into visual parameters. That makes them cousins of data visualization, but with different success criteria: timing, feel, legibility, and performance resilience matter as much as analytical accuracy.

The graph should distinguish analytical visualization from performance visualization. A spectrogram, waveform overview, oscilloscope, DJ deck, stage visual, and installation patch all show sound, but they are built for different forms of attention.

Digital audio workstations include Ableton Live (opens in new tab), Reaper (opens in new tab), Logic Pro, Cubase, Pro Tools, FL Studio, Bitwig Studio, and many smaller tools. The important record is not "which DAW is best." It is whether the project can be opened, rendered, edited, performed, and understood later.

Visual and interactive systems include Resolume (opens in new tab), VDMX, MadMapper, TouchDesigner, Isadora, Max, p5.js, Processing, Three.js, and custom code. Max (opens in new tab) and TouchDesigner (opens in new tab) are especially useful examples because they make the patch itself part of the performance record: nodes, signals, timing, media files, device inputs, and output mapping are all visible artifacts.

For computational work, Python often handles analysis, batch processing, metadata cleanup, MIR experiments, and dataset work. Wasm matters when audio, DSP, synthesis, notation, or visualization kernels need to run near a browser interface with predictable performance and a clear sandbox boundary.

Session files are fragile because they depend on plugins, sample paths, operating-system behavior, copy protection, and hardware assumptions. Durable music archives usually include the editable session, printed stems, MIDI, bounced reference mixes, tempo maps, notes about nonstandard tunings, artwork, cue sheets, and licensing context. For long-lived projects, treat open formats and exported audio like data storage, not an afterthought.

The practical interchange formats are not perfect. WAV and AIFF preserve audio well, FLAC preserves lossless distribution efficiently, MIDI preserves performance instructions, MusicXML can preserve notation, and stems preserve arrangement decisions, but none fully capture the social context of a session. A good archive therefore includes plain-language notes: who played what, what cannot be recreated, what is approved for release, and which decisions were aesthetic rather than technical.

Important standards and formats include WAV, AIFF, FLAC, MP3, AAC, MIDI, MusicXML, OSC, MPE, VST, Audio Unit, LV2, ADM/BWF, ISRC, ISWC, and common loudness targets. The exact set depends on whether the project is a recording, performance rig, interactive installation, sample library, archival transfer, or web instrument.

Stable references include the MIDI Association (opens in new tab), the W3C Web Audio API (opens in new tab), the W3C MusicXML 4.0 specification (opens in new tab), MusicBrainz (opens in new tab) for open music metadata, ISRC (opens in new tab) for recording identifiers, and ISWC (opens in new tab) for musical-work identifiers.

This is where music connects to standards, semantic web, Wasm, and data storage: interchange decisions decide what can be played, analyzed, licensed, linked, and preserved later.

Every production or performance rig has a signal flow contract: what creates sound, what controls it, where it is processed, where it is monitored, what is recorded, and what happens when a device fails. Draw the chain before the session matters. Inputs, clock source, sample rate, controller mapping, plugin latency, routing, speakers, projectors, lighting, recording path, and emergency playback should all be legible.

This is where music overlaps with human-machine interaction and data visualization. A good controller layout or live visual patch is not only expressive; it makes state visible fast enough for a human performer to recover.

Music files carry more than sound. Rights splits, sample licenses, performer credits, producer credits, publisher data, ISRCs, ISWCs, artwork, release dates, cue sheets, stems, session notes, takedown constraints, and synchronization terms decide whether work can be released, remixed, archived, or paired with video.

Treat those records as part of data storage, books, and the semantic web. A release is a bibliographic object as much as an audio object: title, contributors, label, date, edition, medium, identifiers, territory, and rights all shape how it can be found and cited.

Music becomes data in several ways: audio features, notation, lyrics, playlists, credits, listening histories, recommendation embeddings, catalog identifiers, fingerprints, and rights metadata. Each view is partial. A recommendation vector may capture similarity without authorship. A waveform may preserve sound without lyrics. A score may preserve notes without production. A playlist may preserve social context without musical structure.

For mathematics, music is a friendly example of ratios, rhythm, periodicity, transformations, tuning systems, graphs, and signal analysis. For language, lyrics, titles, transliteration, and genre names create ordinary multilingual metadata problems. For semantic web, music shows why identifiers matter: a work, recording, release, artist, and file can all have different identities.

Music archives need status labels because musical objects are often revised, remastered, reissued, sampled, synchronized, and redistributed. A project can contain a sketch, demo, arrangement, rehearsal recording, live capture, mix print, master, instrumental stem, archival transfer, release candidate, published release, takedown copy, rights-cleared asset, or private reference. Those are not interchangeable, even when they share a title.

For creative work, the label protects process. A rough bounce should stay available for memory without being mistaken for a mastered release. For data storage, the label protects rebuildability by identifying which files are source sessions, rendered derivatives, external samples, backups, or distribution artifacts. For standards, the label clarifies which identifiers belong to works, recordings, releases, contributors, and licenses.

A reader workflow should start by asking what kind of object is being described: composition, performance, recording, session, release, visual system, dataset, or rights record. Then inspect the evidence: audio, notation, metadata, catalog entry, liner notes, source repository, session export, or public archive. The graph becomes useful when it can show which recordings derive from which sessions, which releases reuse which masters, which visuals respond to which audio features, and which claims depend on listening rather than metadata alone.

Music pages should keep listening evidence and metadata evidence in conversation. Listening can reveal tempo feel, arrangement, production choices, tuning, space, gesture, and emotional contour. Metadata can reveal contributors, dates, rights, identifiers, formats, versions, and distribution history. Either side can be wrong alone. A catalog can miscredit a track; a listener can mistake a remaster for the original; a waveform can prove duration without explaining authorship.

The practical workflow is to cite what can be cited and describe what must be heard. When a claim comes from a public catalog, name the catalog. When a claim comes from the audio itself, keep the language observational: the mix foregrounds a rhythm, the recording includes room tone, the performance changes tempo, the visual system reacts to amplitude or frequency bands. That habit makes music usable as art, data visualization, and human-machine interaction without flattening it into either vibes or metadata.

Useful music edges include composed_by, performed_by, recorded_by, produced_by, mixed_by, mastered_by, samples, interpolates, arranged_for, notated_as, rendered_to, released_on, licensed_under, identified_by, synchronized_with, visualizes_audio, uses_controller, uses_plugin, stored_as, and derived_from.

The graph should also preserve uncertainty. "Influenced by," "sounds like," "sampled," "covered," "remixed," and "used the same chord progression" are not the same claim. A strong music graph keeps the evidence close: audio comparison, liner note, rights database, producer interview, score, session file, or catalog record.

Music preservation is easiest before the project feels finished. A good archive keeps the final master, instrumental, stems, session file, exported MIDI, score or chart, plugin list, sample sources, cover art, rights notes, release identifiers, and a plain-text readme in the same preservation bundle. The readme should name the DAW, version, sample rate, bit depth, tempo map, tuning, routing assumptions, and known missing dependencies.

The point is not bureaucracy. It is future playability. A live set, installation, or score can become unreadable because one plugin, controller mapping, font, sample folder, or operating-system behavior disappeared. A small recovery note can save the work. This connects music to data storage, standards, Wasm, and human-machine interaction: the artifact includes sound, interface, timing, and fallback paths.

For public releases, recovery also means preserving identifiers and context. ISRC, ISWC, MusicBrainz IDs, label copy, distributor records, credits, artwork, license, and publication date all help future readers distinguish an original, remaster, live version, edit, cover, sample, and derivative work.

Not every musical claim can be reduced to metadata. Some claims come from listening: a mix is dry, a rhythm pushes ahead of the beat, a room is audible, a melody returns in another instrument, a visual patch follows amplitude rather than pitch. Those are observations, and they should be written as observations rather than elevated into unsupported biography or intention.

A useful listening note names the audio object, timestamp or section, observable feature, and uncertainty. If a claim depends on a score, catalog, rights database, interview, or session file, cite that instead. If it depends on hearing, say what was heard. This discipline makes music pages better neighbors for art, language, symbols, data visualization, and multimodal AI, because the graph can distinguish catalog fact, sonic observation, interpretation, and generated caption.

Music systems fail in ordinary ways: noisy power, bad cables, missing licenses, mismatched sample rates, uncalibrated monitoring, forgotten exports, undocumented routing, and fragile plugin chains. Live audiovisual systems add frame-rate drops, projector mismatch, MIDI clock drift, stage-lighting conflicts, venue power, and audience-visible recovery time.

The professional habit is to make the work recoverable. Label the rig, rehearse a fallback, keep a stereo emergency playback path, print stems, write down the working version, and preserve the project state after each successful performance or release.

Useful starting points should separate learning, recording tools, audio analysis, metadata, identifiers, and interchange standards.

For compendium work, the important learning path is not only "learn a DAW." It is: learn to listen, preserve the session, document the signal chain, name the rights, export portable artifacts, and keep enough context that another person can understand what the sound is, where it came from, and what may be done with it.

• Ableton Learning Music (opens in new tab)
• Sound On Sound (opens in new tab)
• Audacity (opens in new tab)
• librosa documentation (opens in new tab)
• Internet Archive audio collection (opens in new tab)
• MusicBrainz (opens in new tab)
• MIDI Association (opens in new tab)
• Web Audio API (opens in new tab)
• MusicXML 4.0 specification (opens in new tab)
• ISRC (opens in new tab)
• ISWC (opens in new tab)
• Max (opens in new tab)
• TouchDesigner (opens in new tab)

• Art for music as cultural memory, performance, and form.
• Design for interfaces, instruments, stage layouts, and release surfaces.
• Symbols and language for notation, lyrics, signs, and metadata.
• Human-Machine Interaction for latency, feedback, recovery, and control surfaces.
• Data Storage for sessions, stems, masters, metadata, and archival risk.
• Standards for MIDI, MusicXML, Web Audio, identifiers, and formats.
• Data Visualization for waveforms, spectrograms, visual music, and graph displays.
• Wasm and Python for browser audio, DSP, analysis, and metadata tools.