MIDI Note Sequence File Builder

How to use MIDI Note Sequence File Builder

Prepare a short original sequence for manual import into your chosen music application. Enter when each note starts, how long it lasts, its MIDI pitch number, velocity and channel. The local build creates one ordered Standard MIDI File track and a separate complete source report.

1. Enter your original note rows or select one local UTF-8 file. Keep the exact five-column header; each data row represents one note interval.
2. Set PPQN and quarter-note tempo. Choose a raw program number only when you intend to send that program value to each used channel in a later external player.
3. Run the local build and inspect note count, exact tick positions and stored tempo. Resolve any same-channel, same-pitch overlap or tick-grid error rather than accepting a silent adjustment.
4. Download the complete MIDI file or JSON evidence. Copy contains the small current summary. Open the file yourself in your intended application and verify its timing and sound before using it.

Good to know

• This writes one Standard MIDI File format 0 with one PPQN track. It does not play audio, transmit MIDI, connect to hardware, import into a sequencer, infer a score or certify compatibility. Recipient instruments, program banks and channel conventions determine any later sound. There is no music library or copyright assessment.
• Use 1–500 rows and at most 50,000 source UTF-16 units. An optional actual File has 1–50,000 bytes, a single-line Unicode basename of at most 200 UTF-16 units and one 5-second read deadline. Invalid UTF-8, changed byte count, unsupported fields or any over-budget complete result refuses atomically. Selected File data replaces pasted rows.
• The selected comma-separated profile has exactly start,duration,note,velocity,channel headers, with optional ASCII spaces or tabs around cells. One initial BOM is an encoding marker; CRLF and bare CR become logical LF lines. One final line ending is allowed. Blank records, quotes, multiline cells, missing/extra cells, arbitrary expressions and non-ASCII source are unsupported. Full original source spelling and source record numbers remain in JSON.
• Start and positive duration are ordinary decimal quarter-note beat strings with at most 6 fractional places and magnitude at most 1,000,000. Each must map exactly to integer ticks on PPQN 1–32,767; there is no hidden note quantization or duration clamping. Every end tick is at most 268,435,455. Notes 0–127, velocities 1–127 and channels 1–16 require canonical whole-number digits. Note-off release velocity is fixed at 64.
• Overlapping intervals on the same channel and pitch are refused. Adjacent intervals are allowed. At a shared tick, note-offs precede note-ons, followed by original record order within each event kind. Different pitches/channels may overlap. Every message repeats its status byte; no running-status compression or voice-allocation inference occurs.
• The sequence name is printable ASCII for this conservative metadata profile. Fixed 4/4 metadata, the name and tempo are written at tick zero; the time signature does not alter quarter-note input units. Optional raw program 0–127 is sent once for each used channel. No SysEx, controller, lyrics, SMPTE, MIDI 2.0, format 1/2 or existing-file conversion is included.
• Tempo is 20–300 quarter-note beats per minute with at most 3 decimal places. The file stores integer microseconds per quarter note, rounded to nearest with exact half-up ties. JSON preserves the entered tempo, encoded tempo and exact resulting rate and elapsed-time fractions. An arbitrary decimal BPM is not always exactly representable in this field.
• Both complete artifacts are checked before either mode returns: MIDI at most 16,384 bytes; JSON at most 300,000 UTF-16 units and UTF-8 bytes. JSON contains current source, the selected filename, authored metadata and every generated event; review it before sharing. The visible/copy summary is small and is not the full event report.
• No upload, account, automatic save or persistent history is used. A pending File read is rejected on pagehide; the already requested browser read may finish later but cannot restore its failed result. Reset and a new run use the site generation guard to discard old UI results; they do not promise an immediate abort of the browser file-read operation.