giers10/ep-133-project-export
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Docs: Add musician workflow inventory and audit README for EP-133 to Live 10

Browse Source
This commit is contained in:
Victor Giers
2026-07-14 00:17:22 +02:00
parent 3b3c4d1cb9
commit 7dae718d11
2 changed files with 152 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

90
docs/research/ep133-musician-audit/MUSICIAN_WORKFLOW_INVENTORY.md Normal file
View File

@@ -0,0 +1,90 @@
# Musician workflow inventory
## A realistic way to make a KO II track
A musician rarely thinks in TAR members. A common workflow is:
1. Choose a tempo, tonal center/scale and rhythmic feel.
2. Give the four groups musical jobs, such as drums, bass, harmony and vocals/lead.
3. Load, record or chop source audio onto pads.
4. Make different instruments from the same sample by changing trim, AMP, pitch, pan, envelope, play mode, root note and time mode per pad.
5. Record notes live, step-sequence precise events, play a sample chromatically in KEYS, and add pressure-shaped note repeats.
6. Record several fader assignments into the same group pattern: level, filters, pitch, FX send, attack/release, pan, velocity and modulation.
7. Choose one send FX for the project, set its X/Y character, set each group send, then shape the summed result with output compression and note-triggered sidechain.
8. Commit working combinations of the four group patterns into scenes, then make variations without stopping playback.
9. Arrange scenes—including repeats and returns—into song positions.
10. Perform temporary loops, group solos and pressure-sensitive punch-in FX. When one of those performances is compositionally important, resample it onto a pad so its sound becomes durable.
That last step is a central sampler workflow: some “effects automation” is not automation data at all. It is a performance rendered into a new sample and then sequenced like any other sound.
## What a project can contain from a musician's perspective
| Musical layer | Decisions a musician can make | Persistence class | Live 10 reproduction question |
|---|---|---|---|
| Project frame | BPM; key and scale on current firmware; swing | Saved project state, although exact binary locations are not all decoded | Does Live open at the same tempo, show the tonal context and play the same swing? |
| Group organization | Four simultaneously playing groups, each containing twelve pad/sample tracks | Saved project state | Are A–D preserved as Group Tracks with their pads underneath? |
| Pad assignment | Global sample slot chosen independently for every pad; the same slot may be used by several pads | Saved project state plus separate sample library | Does each pad become an independent instrument even when two pads share one WAV? |
| Pad sound design | trim, AMP, pitch/fraction, pan, attack, release, play mode, root note, time mode/BPM/bars, mute-group membership, MIDI channel | Saved per-project pad state | Does each duplicated pad retain its own articulation and gain? |
| Audio provenance | mic, line, USB or resample; mono/stereo and multiple supported sample rates | WAV/sample-library state | Is the actual audio copied and played at the correct native rate/channel count? |
| Cropping | Commit trim points destructively into the global sample file | Baked/destructive audio state | Live only needs the resulting WAV; it cannot restore the discarded audio. |
| Chopping | Auto/equal/attack/live chop creates several pad assignments and trim regions, often referencing one slot | Saved pad state | Are all slices independent and do their trim boundaries remain exact? |
| Notes | pad/source, tick position at 96 PPQN, note pitch, velocity and duration | Saved pattern events | Are groove, microtiming, dynamics, pitched notes and held lengths retained? |
| Recording method | live, quantized, free-time, step entry, note repeat, arpeggio, timing correct and nudging | Usually collapses into note events; the gesture itself is not important once recorded | Does Live reproduce the resulting events rather than the input gesture? |
| Pattern structure | A separate pattern selection and length for each group; shorter group patterns repeat while the scene lasts as long as its longest pattern | Saved pattern and scene state | Are independent loop lengths and repetitions represented without flattening the scene incorrectly? |
| Meter | time signature can be changed for the current pattern/scene, including non-4/4 material | Saved scene/pattern state in current reverse engineering | Does a 3/4 section occupy the right musical time and return cleanly to 4/4? |
| Recorded fader motion | multiple parameter lanes can coexist in one group pattern even though there is one physical fader | Saved pattern events | Does every lane appear at the right group/pattern time with correct scaling? |
| Static fader bases | starting value for each of twelve group parameters | Saved settings state | Does a pattern begin with the intended mix/filter/pitch/send state before automation? |
| Group project volume | non-automatable level across all patterns/scenes | Runtime project mix control; official release notes say it resets when a project loads | A backup cannot be assumed to describe the musician's temporary listening level. |
| Scene | one A/B/C/D pattern combination and meter | Saved project state | Does each unique section become a Session row and an Arrangement section? |
| Song list | up to 99 positions, each referring to a scene; scenes may repeat or return in any order | Saved project state | Does Arrangement follow the actual song positions rather than numeric scene order? |
| Send FX | one selected project FX: delay, reverb, distortion, chorus, filter or compressor; static X/Y; per-group FX send | Saved settings state; group send can be automated | Is there one Return with the right character, and are sends placed on the four groups? |
| Output dynamics | separate master compressor DRIVE/SPEED after dry groups plus the send return | Saved project state according to current reverse engineering | Does the Live Master reproduce the broad dynamics and AMP interaction? |
| Sidechain | one or more source pads; destination groups; note-triggered length/shape, including silent triggers | Saved output settings according to current reverse engineering | Does every source note duck the selected groups even when its source pad is silent? |
| MIDI sequencing | a pad can address a MIDI channel/root; empty pads can sequence external gear; recorded MIDI can include notes and some expression/controller messages | Saved pad and pattern state, with some event semantics still unresolved | Does Live create usable external-MIDI lanes and preserve non-note expression? |
| Resampling | bounce a pattern, chord, layered sounds or effect performance to a new mono/stereo sample | Baked audio plus a new sample slot | Is the rendered WAV present and sequenced correctly, without pretending the source process is editable? |
| Live X/Y during resampling | current firmware allows send-FX X/Y changes during latched resampling | Baked audio only unless another event stream is discovered | Does the baked sweep sound correct? Reconstructing the knob motion is not required. |
| Punch-in FX | pressure-sensitive, combinable beat/tape/pitch-style performance effects | Live-only unless resampled or externally recorded | Is the audit explicit that a plain backup cannot reproduce the performance? |
| LOOP and slide | temporary tempo-locked capture/slide/length performance | Live-only unless resampled or externally recorded | Same: absence from the archive is different from an exporter omission. |
| Group solo/manual scene switching | performance choices while playing | Live-only unless represented by song positions, resampling or an external recording | The exported set may offer equivalent performance controls, but cannot infer what was previously performed. |
| Live input processing | external audio can be sent through the selected FX | External/live-only unless sampled | Project data cannot supply the absent external performance. |
## What “faithful in Live” means to a musician
The audit should be judged in layers:
1. **Composition:** the same hits, pitches, velocities, durations, microtiming, patterns, scenes and song order.
2. **Instrument articulation:** the same trim, tuning, start behavior, polyphony/legato intent, envelope, stretch/reverse behavior and choke relationships.
3. **Mix:** independent pad AMP, A–D group levels/pans, fader automation and FX sends.
4. **Shared processing:** selected send FX, output dynamics and note-triggered sidechain.
5. **Rendered history:** resampled material must sound like its WAV, even though its pre-bounce layers are no longer editable.
6. **Performance boundary:** unsaved punch-ins, loops, solos and external input are documented as unknowable rather than silently classified as lost project data.
These layers prevent a structurally impressive Live set from being called faithful when the musical form or shared dynamics are missing.
## Musician-derived stress cases
The imaginary project intentionally includes the situations most likely to reveal a translation problem:
- one WAV assigned to several pads in the same group with different AMP, trim, pitch and pan;
- ONE, KEY and LEG instruments in the same project;
- both BPM and BAR stretch plus reverse playback;
- open/closed hats in the shared mute group;
- free-time ghost notes alongside swung quantized hats;
- multiple fader lanes in a single pattern;
- independent group-pattern lengths inside one scene;
- a non-4/4 scene;
- repeated and non-numeric scene order in the song list;
- a silent sidechain trigger;
- a resampled performance with baked FX motion;
- an empty MIDI pad carrying notes and expression for an external synth;
- live punch-in and LOOP gestures that are deliberately *not* treated as project data.
## Firmware-sensitive observations
- OS 2.0 made swing project-scoped.
- OS 2.5 saves key and scale per project and adds FX X/Y changes during latched resampling.
- OS 2.5 improves BAR stretch in non-4/4 meters and MIDI Song Position Pointer behavior.
- The official 1.1.2 release notes say group project volume resets when loading a project, so it should not be treated as durable archived mix state without contrary capture evidence.
- Current firmware can record/relay MIDI program change and records pitch-bend/aftertouch-style input, even though the exact project-event semantics are not all decoded.
Sources: [current feature notes](https://teenage.engineering/guides/ep-133/whats-new), [OS history](https://teenage.engineering/downloads/ep-133), [official modes](https://teenage.engineering/guides/ep-133/modes), [official play/record guide](https://teenage.engineering/guides/ep-133/play-and-record), [official sampling/timing guide](https://teenage.engineering/guides/ep-133/functions), and [official effects guide](https://teenage.engineering/guides/ep-133/effects).

62
docs/research/ep133-musician-audit/README.md Normal file
View File

@@ -0,0 +1,62 @@
# EP-133 musician-to-Live 10 translation audit
This research set asks a musician's question rather than a file-format question:
> If a finished EP-133 project sounds and behaves a certain way in the hands of its creator, which parts of that musical work appear in the exported Ableton Live 10 set?
It deliberately does not propose code changes. It supplies a musical reference project and a diagnostic vocabulary that can be used before implementation decisions are made.
## Files
- `MUSICIAN_WORKFLOW_INVENTORY.md` describes how a musician can build and perform an EP-133 project and separates saved project state from rendered audio and live-only gestures.
- `IMAGINARY_PROJECT_AFTERIMAGE_TRANSIT.md` specifies one coherent imaginary project in enough detail to act as a translation oracle.
- `LIVE10_TRANSLATION_AUDIT.md` asks whether the current group-track Live 10 export represents every decision in that imaginary project.
## The three kinds of musical truth
| Kind | Meaning | Example | What an archive-based exporter can know |
|---|---|---|---|
| Saved state | Data represented in project/sample files | notes, pad trim, song positions, recorded fader motion | Potentially knowable if the format is decoded |
| Baked audio | A gesture whose result became a new WAV | a chord resampled while changing reverb X/Y | The resulting sound is knowable; the original gesture and device chain are not necessarily recoverable |
| Live-only performance | A gesture heard during a performance but not recorded into project data | punch-in FX, temporary loop, group solo | Not recoverable from a later backup unless it was resampled or recorded externally |
This distinction is essential. “Not present in the Live set” can mean four different things:
1. the EP saved it and the exporter translated it;
2. the EP saved it but the exporter approximated or omitted it;
3. the EP baked it into sample audio, so only the audible result survives;
4. the EP never saved it, so an archive export cannot reconstruct it.
## Audit vocabulary
| Status | Meaning |
|---|---|
| Represented | The current exporter creates a usable Live counterpart from the saved data. This does not imply bit-identical audio. |
| Approximate | The musical intent is present, but device behavior or parameter scaling differs. |
| Partial | Some required state is translated and some is omitted or misread. |
| Missing | The EP state is available or strongly evidenced, but the current exporter does not put it in Live. |
| Baked only | Live can receive the rendered sample, not the process that created it. |
| Unknowable from archive | The gesture is not part of the saved project/sample state. |
| Unresolved | More EP-side evidence is needed before the expected translation can be stated safely. |
## Evidence policy
Musical behavior is taken primarily from the current official EP-133 v2.5 guide and release notes. Community tutorials are used to understand how musicians combine the features into songs, not as authority for binary offsets or DSP laws. Binary claims are checked against the supplied OS 2.5.1 backup and the local parser.
The imaginary project is not a claim that a particular TAR already exists. It is a design oracle: every item should either be possible on the device, explicitly identified as a live gesture, or marked as an open question.
## Primary sources
- [EP-133 workflow: projects, groups, patterns, scenes, commit and song positions](https://teenage.engineering/guides/ep-133/workflow)
- [Sound editing, play modes, time stretch, MIDI, mute groups and song mode](https://teenage.engineering/guides/ep-133/modes)
- [Notes, velocity, duration, fader recording and group project volume](https://teenage.engineering/guides/ep-133/play-and-record)
- [Sampling, resampling, chopping, timing, swing, note repeat and loop performance](https://teenage.engineering/guides/ep-133/functions)
- [Send FX, punch-in FX, output compressor and note-triggered sidechain](https://teenage.engineering/guides/ep-133/effects)
- [Current feature and firmware behavior changes](https://teenage.engineering/guides/ep-133/whats-new)
- [Official OS release history](https://teenage.engineering/downloads/ep-133)
## Musician-workflow references
- [Music Room Academy: from an empty project to a finished track](https://musicroom.academy/blog-from-empty-project-to-finished-track-step-by-step/) — useful for role-based groups, motif development, energy-shaped scenes and song form.
- [Rochefsky EP-133 tutorials](https://www.rochefsky.com/learnings/TeenageEngineering-EP-133) — useful for the practical load-sounds → record-patterns → commit-scenes → perform-with-effects workflow.
- [Sound On Sound EP-133 review](https://www.soundonsound.com/reviews/teenage-engineering-ep-133-ko-ii) — useful for the hands-on commit/performance perspective, but written before later firmware added resampling, sidechain and song mode; obsolete feature-limit claims are not used here.