LowEnd Forge export

LowEnd Forge Export Formats: What Each File Preserves

The current LowEnd Forge desktop export menu exposes PDF, MIDI, bass-only WAV, and no-bass WAV. The versioned .lforge project is the editable source of truth. The backend also contains MusicXML and plain-text renderers, but the current desktop UI does not expose either action.

Choose an output for its destination, not because one file sounds more universal. No exported PDF, MIDI file, or WAV file can preserve the complete project.

Quick comparison

Format	Current availability	Preserves	Does not preserve
`.lforge` project	Community	Analysis context, project assets, note draft, mixer and workspace state, licensed edits	Generic compatibility outside LowEnd Forge
Bass-only WAV	Community	Rendered bass-stem audio	Editable notes, tab, tuning, analysis state
No-bass WAV	Community	Rendered accompaniment audio	Editable notes, tab, tuning, analysis state
MIDI	Professional feature	Pitch, start, duration, velocity, tempo and supported metadata	Bass string/fret fingering and full project state
PDF	Professional feature	A stable rendered bass-tab page	Round-trip editing and source audio
MusicXML backend	Paid feature registered; no current desktop action	Basic pitch and duration notation	Reliable measures, timing placement, tab fingering, full score structure
Plain-text backend	No current desktop action	Inspectable event rows	Engraving, playback, and editable project context

If another LowEnd Forge user must continue editing, send the .lforge project rather than an export. If a DAW needs note events, choose MIDI. If a player needs a readable page, choose PDF. If a musician needs practice audio, choose one of the WAV mixes.

`.lforge`: the canonical editable project

Save the project before exporting. A versioned .lforge document can preserve the source and generated asset context, bass and accompaniment stems, transcription state, selected tuning, mixer state, workspace settings, and edits enabled by the user's edition.

The project bundle is designed to move and reopen as one working document. It is still wise to keep the original recording separately. Use Save As before destructive or large-scale editing so that you have a known-good checkpoint.

Do not rename a PDF or MIDI file to .lforge; the extension describes a structured LowEnd Forge project, not an arbitrary container. Likewise, an exported file cannot be imported later with an expectation that it will reconstruct analysis confidence, waveform state, chord regions, or editing history.

Bass-only WAV

Bass-only WAV renders the isolated bass result as audio. It is useful for focused listening, learning a line, checking attacks, or handing a bass-focused stem to a compatible audio workflow.

This is an estimated stem extracted from a finished mix. It can contain kick-drum bleed, vocal or guitar remnants, transient smearing, and warbling. Export does not improve the separation; it writes the current result. Listen to the beginning, a dense section, a quiet section, and the ending before sharing.

The WAV file contains audio rather than bass-tab events. Changing its filename or opening it in a DAW does not restore string, fret, confidence, tuning, or analysis metadata.

No-bass WAV

No-bass WAV renders the accompaniment or bass-removed result. It is intended for bass practice, rehearsal, or an audio handoff where the player supplies the bass part.

Because separation is an estimate, the backing track may retain low-frequency bass information or remove some overlapping energy from kick drum, low guitar, or keyboards. Test the exported track on headphones and speakers. Confirm that its duration and start point match the original before using it in a rehearsal.

Bass-only and no-bass WAV export are part of the Community workflow. They do not require MIDI or PDF export access.

PDF: a rendered bass-tab snapshot

Use PDF when a bandmate, student, or reviewer needs a stable page rather than an editable interchange file. The current renderer uses the project's bass string/fret lanes and can include the title, tuning, tempo, time signature, key label, quantization grid, and chord markers when those values exist.

PDF is a presentation snapshot. Reopen the generated file and check page breaks, string labels, fret numbers, rhythm, title, and chord placement before sharing it. It is not a round-trip project format and cannot reproduce the audio or editable timeline.

If specialized articulations, repeat structures, engraving rules, or performance notes are required, add them in a dedicated notation workflow after validating the underlying events. The current LowEnd Forge editor does not expose articulation editing.

MIDI: pitch and playback timing

Use MIDI for a DAW, virtual instrument, or note-timing handoff. The bass track carries note pitch, start time, duration, and velocity. The conductor track carries tempo and can carry the project time signature, key signature, and chord markers. A drum track is included when drum events exist.

MIDI does not encode the bass string and fret choice as tablature. Several fretboard positions can produce the same MIDI pitch, and the receiving application may choose a different octave display or instrument patch. After import, verify:

tempo and time signature;
track and MIDI-channel assignment;
octave and instrument range;
first and last event placement;
repeated notes of the same pitch;
note lengths and overlaps.

Keep the LowEnd Forge project when fingering decisions matter. Export MIDI only after correcting the draft; otherwise the destination receives model errors with a different file extension.

MusicXML: a limited backend renderer

The current MusicXML backend renderer is intentionally basic, and the current desktop UI does not expose it. Although the product's paid capability registry includes MusicXML export, users should not plan a current desktop workflow around a missing menu action.

The renderer writes a single bass-clef part in one 4/4 measure, with note pitches and durations derived from the reviewed note list. It can write a tempo marking, but it does not currently preserve note start positions, bar structure, pickup measures, repeats, ties, tuplets, string/fret assignments, tab staff, or the project's key signature.

If this backend becomes exposed in a future release, use its file only to seed a notation editor. Rebuild measures and tab positions in the receiving application, then compare the imported result with the source recording. Do not treat it as a lossless score or tab handoff.

Plain text: an inspectable event inventory

The backend text renderer creates a tab-separated review record rather than an ASCII-art score, but the current desktop UI does not expose it. It lists bass notes with pitch, start time, duration, and velocity. When available, it also lists string/fret events, chord ranges and confidence, and drum events.

This format can support debugging, spreadsheets, scripts, or a compact human-readable audit. It does not reproduce engraving, playback, project assets, or a complete editing session.

A destination-based decision table

Destination	Recommended output	Required follow-up
Another LowEnd Forge computer	`.lforge`	Reopen and confirm bundled assets
DAW or virtual instrument	MIDI	Set instrument, verify octave and timing
Bandmate reading tab	PDF	Inspect page breaks and fingering
Bass practice without the original bass	No-bass WAV	Listen for separation artifacts
Detailed listening to the bass	Bass-only WAV	Compare questionable events with original mix
Notation editor	MIDI today	Rebuild tab positions and engraving manually

Do not send only one export when the recipient may need revisions. Keep the .lforge project and original audio under your control, and record which output was approved.

Export QA procedure

Save the source audio and .lforge project without overwriting either one.
Review the transcription using the original mix and bass stem.
Export to a new, clearly named file.
Reopen the file in the actual destination application.
Compare the first event, a dense middle passage, and the final event.
Check tempo, octave, duration, and any expected string/fret data.
Listen for WAV clipping, silence, drift, or missing sections.
Record which notation details were rebuilt after import.

For correction before export, use the bass-tab editing guide. For the shortest path through a new project, start with the LowEnd Forge quickstart.

Frequently asked questions

Which format keeps all my edits?

The .lforge project is the editable source of truth. PDF, MIDI, and WAV are destination outputs and do not preserve the complete session.

Why does MIDI lose my bass fingering?

Standard MIDI represents note pitch and timing, not LowEnd Forge's string and fret choices. Recreate or verify tablature in the receiving application.

Can I export MusicXML from the current desktop menu?

No. A backend renderer and paid capability entry exist, but the current desktop UI does not expose a MusicXML action.

Are WAV exports lossless transcriptions?

No. WAV preserves rendered audio samples, not the transcription model or editable notes. The separated audio itself can contain artifacts.

Does PDF prove the transcription is correct?

No. PDF stabilizes the reviewed page. Accuracy still depends on comparing the events and fingering with the recording.

For supported platforms, current editions, and downloads, visit the LowEnd Forge product page.

Direct answer and acceptance boundary

For “LowEnd Forge Export Formats: What Each File Preserves”, the short answer is: Compare LowEnd Forge project, PDF, MIDI, and WAV outputs, including edition limits and the data each format preserves or loses. Treat that statement as a result to verify, not as a promise that every input, device, project, or environment behaves identically. A complete result records the starting state, the exact action, the visible output, and the condition that proves the task is finished in LowEnd Forge.

Evidence-first operating procedure

Work from a small, repeatable case before changing a full project. Record the application version, operating system, input or device identity, relevant settings, and the expected result. Perform one deliberate action, preserve the first unexpected transition, and compare it with a known-good run whenever one is available. Changing several controls at once may hide which condition fixed or created the problem.

Checkpoint 1: LowEnd Forge Export Formats: What Each File Preserves

Treat “LowEnd Forge Export Formats: What Each File Preserves” as a separate acceptance gate for “LowEnd Forge Export Formats: What Each File Preserves”. Record its initial state before acting, then capture the first visible change and the final state. If the result differs from the page’s stated outcome, return to the last confirmed checkpoint instead of continuing with assumptions.

Checkpoint 2: Compare LowEnd Forge project, PDF, MIDI, and WAV outputs, including edition limits and the

Verify “Compare LowEnd Forge project, PDF, MIDI, and WAV outputs, including edition limits and the data each format preserves or loses.” with the smallest representative input. Keep unrelated settings unchanged, repeat the same action once, and note whether the result is stable after reopening or reconnecting. A screenshot alone is weaker than a record that includes the input, setting, action, output, and time.

Checkpoint 3: Quick comparison

For “Quick comparison”, distinguish a product decision from an operating-system, hardware, source-file, permission, or workflow boundary. Confirm which layer supplied the evidence before assigning a cause. This prevents a nearby symptom from being reported as a proven root cause.

Checkpoint 4: .lforge: the canonical editable project

Use “.lforge: the canonical editable project” to define a pass/fail statement that another operator can repeat. Include what should be present, what must be absent, and what recovery action is safe if the check fails. Keep the original project or capture unchanged until the repaired copy has passed the same check.

Checkpoint 5: Bass-only WAV

When “Bass-only WAV” is ambiguous, compare one known-good case with one failing case under matching conditions. Mark the first meaningful difference rather than listing every later symptom. That first boundary usually produces a clearer support request and a safer next experiment.

Checkpoint 6: No-bass WAV

Close “No-bass WAV” only after the saved, exported, or reopened result still matches the observed state. Temporary UI feedback is useful, but durable evidence is stronger. Record any limitation that remains so the next reader does not interpret an incomplete path as a successful one.

Checkpoint 7: PDF: a rendered bass-tab snapshot

Treat “PDF: a rendered bass-tab snapshot” as a separate acceptance gate for “LowEnd Forge Export Formats: What Each File Preserves”. Record its initial state before acting, then capture the first visible change and the final state. If the result differs from the page’s stated outcome, return to the last confirmed checkpoint instead of continuing with assumptions.

Checkpoint 8: MIDI: pitch and playback timing

Verify “MIDI: pitch and playback timing” with the smallest representative input. Keep unrelated settings unchanged, repeat the same action once, and note whether the result is stable after reopening or reconnecting. A screenshot alone is weaker than a record that includes the input, setting, action, output, and time.

Checkpoint 9: MusicXML: a limited backend renderer

For “MusicXML: a limited backend renderer”, distinguish a product decision from an operating-system, hardware, source-file, permission, or workflow boundary. Confirm which layer supplied the evidence before assigning a cause. This prevents a nearby symptom from being reported as a proven root cause.

Checkpoint 10: Plain text: an inspectable event inventory

Use “Plain text: an inspectable event inventory” to define a pass/fail statement that another operator can repeat. Include what should be present, what must be absent, and what recovery action is safe if the check fails. Keep the original project or capture unchanged until the repaired copy has passed the same check.

Acceptance matrix

Checkpoint	Evidence to retain	Pass condition
LowEnd Forge Export Formats: What Each File Preserves	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Compare LowEnd Forge project, PDF, MIDI, and WAV outputs, including edition limits and the data each format preserves or	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Quick comparison	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
.lforge: the canonical editable project	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Bass-only WAV	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
No-bass WAV	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome

Failure isolation, recovery, and handoff

If a check fails, stop at the first failed boundary. Preserve the source, project, session, or capture; duplicate it before destructive editing; and change one variable per experiment. Repeating a broad workflow after several simultaneous changes may produce a different result without explaining why.

Separate absence of evidence from evidence of absence. A blank view may mean the wrong input, scope, filter, permission, device, time range, or project state rather than “nothing happened.” Verify the acquisition or import path before interpreting a decoder, editor, report, or export.

Before handoff, reopen the durable artifact and inspect its beginning, the decision point, and its end. Record version, platform, relevant configuration, expected behavior, observed behavior, and the smallest reproduction. Remove or redact sensitive material and confirm the recipient is authorized to receive it.

Questions and answers

What is the fastest reliable way to start?

Use the smallest representative case, write down the expected result, and change one variable. Confirm the basic path before adding filters, effects, edits, automation, or a larger source. This creates a baseline that can be compared after every later decision.

What evidence should be saved?

Keep the input identity, application version, platform, relevant settings, exact action, first unexpected transition, and final output. If the workflow creates a project, session, report, or export, close and reopen it before treating it as durable evidence.

When should the procedure be repeated?

Repeat it after an application, operating-system, driver, firmware, model, source, or workflow change that can alter the result. Preserve the earlier accepted case so the comparison uses the same acceptance boundary rather than memory.

When is the task ready for handoff?

It is ready when another authorized person can identify the input, repeat the action, see the same result, understand any remaining limitation, and open the saved artifact without relying on undocumented local state.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: