a6fa0d6b8a
Emitting a Marker meta-event from the PART case wrote the event with delta_time_track0 (correct, since that's the conductor-track accumulator) but did not also reset delta_time. On track 0 in multi-track mode, delta_time also accumulates via timestep() and is what writetrack() returns to the MIDI library as the end-of-track delta — so each marker left a stale delta_time that pushed the end-of-track event past the end of the music. In single-track mode (ntracks == 1), markers were written with delta_time_track0 too, but delta_time is the only relevant counter in that mode, so notes following each marker were shifted later. Fix: mirror the TEMPO handler — on ntracks == 1 use delta_time and reset it; on ntracks != 1 keep using delta_time_track0 for the event delta but also zero delta_time so the end-of-track is not inflated. Reported by James Allwright with the partdemo.abc test case (now in samples/), which exercises the parts != -1 path (header P:BACDBAC plus body P: labels A/B/C/D). James independently fixed the same bug in his abc2midiu fork in r32 (commit 34b7c32, "Add -PMAR option for part markers"), where the equivalent reset is on the single delta_time counter — his fork having retired delta_time_track0 in an earlier refactor. Verified that mftext output of the generated MIDI is now byte-identical to the non-PMAR output except for the added Marker events, on both partdemo.abc (single-track) and samples/demo.abc tune 5 with P:(AB)3 (multi-track). Add a CMake/CTest regression test (abc2midi_pmar_partdemo) that locks in the post-fix mftext output. To support it, add_golden_test() gains an optional NAME (to register multiple tests against the same TYPE+SAMPLE pair) and an optional ABC2MIDI_ARGS (forwarded to the abc2midi invocation in run_via_mid). Reverting the genmidi.c fix makes the new test fail; reapplying it makes it pass.
abcMIDI package
abcMIDI is a package of programs written in C for handling abc music notation files. The software was created by James Allwright in the early 1990 and presently maintained by Seymour Shlien. It initially included the following programs:
- abc2midi for converting an abc file to a midi file,
- abc2abc for transposing abc notation to another key signature,
- midi2abc for creating an abc file from a midi file,
- yaps for producing a PostScript file displaying the abc file in common music notation and,
- mftext for creating a text representation of a midi file.
Seymour added two more programs:
- abcmatch for finding common elements in a collection of abc tunes and,
- midicopy for copying parts of a midi file to a new midi file.
Yaps has been superceded by Jef Moine abcm2ps and abc2svg programs. Midi2abc has been expanded to include mftext and various other features for supporting the runabc application. Abc2midi has numerous new features that are described in its own web page abc2midi guide.
Components of the abcMIDI package are parts of numerous applications for creating and editing abc files. Compilations of these components for various operating systems can be found on The ABC Plus Project web page.
The latest version of the abcMIDI package supported by James Allwright can be found can be found here. More recent versions can be found on sourceforge and on the runabc web page.
Building
Autoconf (legacy)
The traditional build uses autoconf:
./configure
make
sudo make install
CMake (modern)
A CMake build system is available alongside the legacy one, with presets for common configurations:
# Configure and build (pick a preset: default, debug, sanitize)
cmake --preset default
cmake --build --preset default
# Install
cmake --install build/default
Available presets:
| Preset | Build type | Description |
|---|---|---|
default |
Release | Optimized build |
debug |
Debug | Debug symbols, no optimization |
sanitize |
Debug | Debug + AddressSanitizer + UndefinedBehaviorSanitizer |
The CMake build generates compile_commands.json for use with
clangd and other LSP-based editors.
Testing
The CMake build includes a test suite covering all 8 programs:
- Smoke tests verify each binary runs cleanly with
-ver. - Golden-file tests run each program on a sample input and compare the
(normalized) output to a checked-in reference. Binary MIDI outputs are
piped through
mftextto produce diffable text. Volatile lines (version banners, dates, temporary paths) are stripped before comparison.
# Run all tests
ctest --preset debug
# Run only golden-file tests / only smoke tests
ctest --preset debug -L golden
ctest --preset debug -L smoke
To regenerate the golden files after an intentional behavioural change, review the diff, then commit:
cmake --build build/debug --target update-golden
git diff tests/golden/
Maintainers / releasing
The package release date in the VERSION file is the single source of
truth for the package version. It is read by CMakeLists.txt (into
ABCMIDI_VERSION) and spliced into configure.ac's AC_INIT via
m4_esyscmd_s at autoreconf time. Each individual program also keeps its
own #define VERSION "<n.nn> <date> <toolname>" in its .c file
(e.g. store.c for abc2midi); these are bumped per-tool when that
tool's behaviour changes.
To cut a release:
- Update the
VERSIONfile (e.g.April 25 2026). - For each tool whose behaviour changed since the last release, bump
its
#define VERSIONstring in the corresponding source file. - Run
autoreconf -fso the committedconfigurepicks up the newAC_INITarguments. The CMake build does not need this step — it readsVERSIONdirectly at configure time. - Run
ctest --preset debugand, if a golden-file test fails because of an intentional output change, regenerate withcmake --build build/debug --target update-goldenand review the diff. - Append an entry to
doc/CHANGESand update the per-tool version listing at the top ofdoc/readme.txt. - Commit and tag.