Skip to content

Sequential Prophet X: read and write the sample instruments (GRP, ZIP) - #429

Open
douglas-carmichael wants to merge 3 commits into
git-moss:mainfrom
douglas-carmichael:prophet-x-format
Open

douglas-carmichael wants to merge 3 commits into
git-moss:mainfrom
douglas-carmichael:prophet-x-format

Conversation

@douglas-carmichael

Copy link
Copy Markdown
Contributor

Adds the sample instruments of the Sequential Prophet X and Prophet XL as a source and a destination. An instrument is a folder with its WAV files and a tab-separated group file (.grp); the device imports it as px/<user bank>/<NN Category>/<name>.zip from a USB drive, which is the layout of the official 8Dio mapping utility and of the free PXToolkit.

Format. Sequential does not document it. The reader of the device was read out of the OS 2.2.2 update image, an unstripped x86-64 QNX executable (GroupFileParse, CWavReader::Open, CSampleGroup::FindHandler, LibraryCopy_ImportFolder): the header line names the columns in any order, the loop end is inclusive, a round robin set is the samples which share key and velocity range and carry a number, Pitch in Hertz is the frequency at which the file sounds and the playback rate is the ratio of the frequency of the key to it, and the sample rate of a WAV file is never read - a file at another rate than the 48 kHz of the engine plays transposed. Volume.txt replaces the built-in velocity table of the device. documentation/design/PROPHET_X_GRP_FORMAT.md records all of it, including what the format cannot carry: the modulation belongs to the programs of the device, and a play range does not exist.

Reading takes the instrument folders and the import archives: key and velocity ranges, loops, round robin sets as groups, root key and tuning from the frequency, key tracking, the category from the folder, the name from the Instrument Name column, and Volume.txt fitted to the amplitude velocity modulator (depth and curve). The empty samples with which PXToolkit keeps unmapped keys silent are skipped.

Writing creates the import archive, or a plain folder, with 16 bit / 48 kHz WAV files stripped to their format and data chunk, the play range of a zone cut into its audio, round robin numbers, an empty sample for the keys which no zone covers - the device plays the nearest zone on them otherwise - and Volume.txt when the velocity response differs from the default. The category is the closest of the 17 categories of the device to the category of the source, or the selected one; the user bank is an option as well. A UUID derived from bank, category and name gives a source which is converted again the same identity.

Checked:

  • A synthetic SFZ (two key zones, two velocity layers, two round robins, 24 bit 44.1 kHz and 16 bit 48 kHz samples, loops, a tune of -20 cents, an offset, 80 % velocity with a cubic curve) through the writer and back through the reader: every value returns, the loops scaled to 48 kHz, the offset cut in.
  • The six archives of the free Goldbaby GBPX Free1 pack, made with PXToolkit for the device: all read (categories from their folders, four round robin groups on the harp, whole-file loops on the noise instruments), and written again after a pass through SFZ every key and velocity range, round robin number and pitch matches the original.
  • The writer of PXToolkit (ProphetWriter.js) is the reference for the conventions above; the written archives are not verified on a device, since none was available.

An instrument is a folder with its WAV files and a tab-separated group
file; the device imports it as px/<bank>/<category>/<name>.zip from a
USB drive. The format was reverse-engineered from the OS 2.2.2 firmware
(an unstripped QNX ELF), see documentation/design/PROPHET_X_GRP_FORMAT.md.

Read: key and velocity ranges, loops (inclusive end), round robin sets
as groups, root key and tuning from the frequency, key tracking, the
category from the folder, the name from the Instrument Name column and
Volume.txt as the velocity response (depth and curve).

Write: the import archive in the USB layout or a plain folder, samples
as 16 bit / 48 kHz since the device ignores the sample rate of a file,
play ranges cut into the audio, round robin numbers, Volume.txt when the
velocity response is not the default, and a UUID derived from bank,
category and name so that a re-conversion keeps the programs of the
device valid. Not yet verified on hardware.
The modulation of a sound (envelopes, filter, LFOs, mod matrix, glide,
bend range) is not part of an instrument but of the program which plays
it. The design document now records what the User's Guide and the
factory bank show about the program dump: the packed 4096-byte layout
with the NRPN number as the byte offset, the name at offset 418 and the
instrument reference by category and index, so that a program writer
can be built on it later. The UUID of an instrument is described as
what the firmware does with it.
… whose archives play

The free PXToolkit is an Electron app, so its writer could be read, and
a third-party sample pack made with it (Goldbaby GBPX Free1) served as
real archives. The detector reads all six of them; the creator now
writes what that tool writes: keys which no zone covers map to an empty
sample so that the device plays nothing on them instead of the nearest
zone, the group file ends its lines with LF, the WAV files carry only
their format and data chunk, and names are reduced to ASCII. The
detector skips those empty filler samples and survives a sample row
which cannot be read. The design document records the conventions, the
pipe character mapping of the importer and the import path on the
device (Global menu, Update Library, User, Update Now).
douglas-carmichael added a commit to douglas-carmichael/ConvertWithMoss that referenced this pull request Sep 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant